не "центрального", а "голого" репозитория, (bare repository). Такие репозитории не обязательно центральные.

Этого момента я не понял. Снова создал, что ли? Ты ведь уже перед этим создал репозиторий при помощи git init. Т.е. ты сейчас средствами SourceTree создаёшь клон на основе этого, только что созданного репозитория (т.е.выполняешь git clone)? Или же ты просто указываешь SourceTree где находится нужный тебе репозиторий (без лишнего клонирования)? На скрине консоли ты пишешь v:, а на скрине SourceTree у тебя указан путь c:\git_tmp. Уточняю на всякий случай, а то вдруг ты действительно клонируешь...

>Все, репозиторий создан. Прежде чем его инициализировать и начинать с ним работать, его надо немного настроить.

Ты его уже инициализировал командой git init.

>Важно! Есть один очень серьезный, и не очень приятный момент: каталоги верхнего уровня не могут иметь первым символом неанглийские буквы. SourceTree, как выяснилось, такие названия не обрабатывает вообще.

Весьма существенный минус, на мой взгляд (ложка дёгтя). Порой переименовывание каталогов может оказаться неприемлемым, т.к. их имена фигурирую в различного рода настройках различных приложений, в т.ч. и в административных утилитах.

> И, наконец, последнее: убираем все файлы из корня сетевого диска:
> /*.*

Не только файлы, но и каталоги, в имени которых присутствует точка.

>Сначала создадим центральный репозиторий, внутри которого не хранятся собственно рабочие файлы. Вызываем терминал, меняем в нем текущий каталог на v:\VersionControl и потом выполняем команду
> git init --bare

Правильней так: "не содержащий рабочего дерева (working tree)".

>По окончании процесса у нас есть рабочая копия, хранящаяся на сервере. Пришло время преобразовать ее в нормальный центральный репозиторий.

На каком ещё "сервере"? Ты ведь работал с виртуальным диском который, по сути - один из каталогов твоего диска D:\. Я не понял, что ты подразумеваешь под "преобразовать"...

> Теперь собственно клонирование «рабочей копии» в «центральный» репозиторий:
> git clone −−bare
>
> Учитывая наши условия, получим нечто типа:
> git clone --bare v:/ v:/versioncontrol

А зачем ты перед этим делал git init --bare для каталога v:\VersionControl? В этом не было необходимости, т.к. git clone --bare v:/ v:/versioncontrol и так сделает всё как надо.

>Возвращаемся в SourceTree, и клонируем репозиторий:

Знакомая картинка... Выше ты её уже скрин с обозначенными путями (хотя там должны были пути начинаться с v:\).

> Возвращаемся в SourceTree, и клонируем репозиторий:
> Указываем, откуда клонируем, куда, задаем имя. Остальные настройки не трогаем. Нажимаем Клонировать.

На скрине указан неверный каталог источника: вместо v:\ должен был быть указан v:\VersionControl, ведь именно его ты назначаешь "центральным" и доступным для выполнения git push.

> Теперь для обоих репозиториев (и того, который на сервере, и локального) устанавливаем в качестве внешнего наш V:\_GIT_VersionControl.

А почему на том же самом локальном диске? В чём соль? Я ещё понимаю, если у тебя:
1) рабочий репозиторий - непосредственно для работы.

2) тот, который ты назвал "центральным" (я бы предпочёл назвать его "расшаренным") так же находится на твоём диске, но доступен по сети др. программерам для выполнения git fetch (т.е. доступен только для чтения).

3) а этот самый _GIT_VersionControl находится в сетевом каталоге, доступный всем программерам только для чтения и лишь их "боссу" для записи - вот это действительно "центральный" репозиторий.

Причём у каждого девелопера свои рабочий и расшаренный репозитории. Каждый девелопер в настройках своих расшаренных и рабочих репозиториев имеет записи для "внешних репозиториев" (remote repositories).

>Возвращаемся в SourceTree:

Что за муть показана на скрине в тексте файла Settings/Users/Users.ini? Сплошные кракозяблы... Смотрю SourceTree серьёзно не дружит с кирилицей, хотя вроде комменты к комитам показывает корректно...

Этот скрин: http://autolisp.ru/wp-content/uploads/2014/03/sourcetreesetup_041.png как-то выподает из общей логики повествования. Неплохо было бы пояснить, что user.name и user.email нужно хранить в конфиг-файлах git (каждый конфиг имеет свою область влияния).

> Крайне желательно нажать кнопку “Обновить”, потом выбрать ветку, с которой надо вытаскивать. Все, жмем ОК.

Неплохо было бы пояснить почему: потому, что если кто-то уже отправил свой коммит в центральный репозиторий, то ты не сможешь сделать этого до тех пор, пока предварительно не синхронизируешься с центральным репом.

>В любой момент, имея несколько ревизий, можно восстановить состояние рабочей копии – достаточно в SourceTree выполнить двойной клик на нужной ревизии. Обновление выполняется практически моментально.

Что подразумевается по "ревизией"? Коммиты, что ли?

> Для объединения желательно выбрать основную (master) ветку и объединять именно с ней.

Чем обусловлено это самое "желательно"? Ветки, при необходимости, можно закидывать и в центральный репозиторий, как альтернативные пути развития ПО.

> http://autolisp.ru/wp-content/uploads/2014/03/sourcetree_branch05.png

Весьма неинформативные имена коммитов.

> 1. Работа выполняется в своем собственном окне

Этой фразы я не понял. Имеется в виду то, что это GUI-приложение, а не консольное?

> Необходимость работы с терминалом при создании центрального репозитория

Странно... Может ты просто плохо искал?

Так и не дождался ответа на вопрос, для чего присутствуют фильтры !App*/**/, !dotnet/**/ и !settings/**/.

Перестал что либо понимать, в виду чего далее пока не читал. Продолжу после того, как ты внесёшь некоторую ясность в обозначенные мною выше вопросы.

К сожалению, невозможно задать такое правило:
*/
!./(Apps|dotnet|settings)/

Это обусловлено тем, что:
An optional prefix "!" which negates the pattern; any matching file excluded by a previous pattern will become included again. It is not possible to re-include a file if a parent directory of that file is excluded. Git doesn’t list excluded directories for performance reasons, so any patterns on contained files have no effect, no matter where they are defined.

Т.о. лучше заблаговременно отделять мух от котлет, дабы не создавать самому себе в прок лишних проблем в будущем.

Позже это может выйти боком, если вдруг по каким-либо причинам реально потребуется связаться с разработчиком.

>Эти данные хранятся в специальном текстовом файле с очень странным (с точки зрения пользователя Windows) именем .gitignore.

На самом деле файлов с настройками игнорирования может быть несколько и имеют они разные имена: .gitignore (находятся в отслеживаемых каталогах), ./.git/info/exclude, а так же шаблоны из файла, указанного в переменной core.excludesFile любого из конфигурационных файлов git. В зависимости от необходимой области действия шаблон задаётся в том или ином файле игнорирования.

>Если строка начинается с символа !, то все, что за ней, обязательным образом обрабатывается
Неверно. Это символ инвертирования результата.

>Проведем небольшой эксперимент. Создадим «временный» репозиторий (в любом каталоге), в его .gitignore вставим наши строки, добавим туда пару каталогов и несколько файлов, отвечающих требованиям игнорирования:

Можно сделать проще: команды git add и git rm поддерживают опцию -n (либо ключ --dry-run). Опция позволяет посмотреть результат работы команды, фактически не выполняя её. Возможно, что и в GUI SourceTree должна присутствовать возможность выполнять аналогичное действие. Если есть возможность открыть консоль git из контекстного меню в проводнике windows (что-то вроде этого: http://www.git-for-win.red-bee.ru/index.html?cui_or_gui.html ), то запустив команду git rm -n "*" можно посмотреть состав выбранных файлов.

>Как видно, такой файл в репозиторий не попадет: он отвечает настройкам .gitignore. И никаких дополнительных действий по указыванию таких файлов выполнять уже не надо.

Если какой либо файл, отсеиваемый фильтрами, всё же по каким-либо соображениям должен быть отслеживаемым, то применительно к нему команда git add должна запускаться с опцией -f.

>Допустим, что мы точно знаем, какие каталоги нам надо сохранять (остальные отправляем в игнор). Это будут каталоги Apps, Settings, ну и, к примеру, DotNet. Нам нужны будут эти каталоги и все их содержимое, независимо от степени вложенности.
># Элементы, которые надо сохранить
>!App*/
>!App*/**/
>!dotnet/
>!dotnet/**/
>!settings/
>!settings/**/

На мой взгляд, это несколько странный набор фильтров... Почему было не ограничиться таким вариантом(?):
#*********************************************
# Элементы, которые надо сохранить
!Apps/
!dotnet/
!settings/
#*********************************************

Согласно указанным мною фильтрам из игнорирования исключаются обозначенные каталоги и всё их содержимое (рекурсивно). Насколько я тебя понял - тебе нужно именно это. В соответствии с процитированным текстом, а так же с этим скрином: http://autolisp.ru/wp-content/uploads/2014/03/svn_folderstruct.png, у тебя только один каталог, имя которого соответствует App* - это каталог Apps, поэтому и в фильтре можно указывать сразу Apps вместо App*.

>По окончании процесса у нас есть рабочая копия, хранящаяся на сервере. Пришло время преобразовать ее в нормальный центральный репозиторий.

Стоп... На каком "сервере"? Ты же работал с локальным каталогом c:\git_tmp (согласно скрину http://autolisp.ru/wp-content/uploads/2014/03/st_gui03.png )...

> На самом деле это не столько создание, сколько “клонирование”. На диске C: создаем каталог git_tmp:

Ты ведь его уже создал ещё в самом начале (согласно обозначенному выше скрину)...