Скотт Чакон - Pro Git

PS> git tfs checkintool

PS> git tfs ct

Выглядит она примерно так:

Рисунок 3. Графическая утилита git-tfs.

Она покажется знакомой для пользователей TFS, потому что это тот же самый диалог, что вызывается из Visual Studio.

Также git-tfs позволяет управлять ветками в TFVC из Git репозитория. Например, создадим новую ветку:

PS> git tfs branch $/tfvc-test/featureBee

The name of the local branch will be : featureBee

C26 = 1d54865c397608c004a2cadce7296f5edc22a7e5

PS> git log --oneline --graph --decorate --all

* 1d54865 (tfs/featureBee) Creation branch $/myproject/featureBee

* ff04e7c (HEAD, tfs/ default, master) update code

* 71a5ddc update readme

* aea74a0 update documentation

| * 44cd729 (tfs/featureA, featureA) Goodbye

| * d202b53 Branched from $/tfvc-test/Trunk

|/

* c403405 Hello

* b75da1a New project

Создание ветки в TFVC означает создание новой ревизии, с которой и стартует ветка, в Git это выглядит как очередная фиксация изменений. Обратите внимание, что git-tfs создалудалённую ветку tfs/featureBee, но указатель HEAD всё ещё находится на ветке master. Если вы хотите продолжать работу в новой ветке, вам нужно базировать новые изменения на коммите 1d54865, создав начиная с неё новую ветку.

git-tf и git-tfs — отличные инструменты для взаимодействия с TFVC сервером. Они позволяют использовать преимущества Git для работы в локальном репозитории, избегая постоянных взаимодействий с центральным TFVC сервером. Это упрощает вашу жизнь, но не заставляет ваших коллег также переходить на Git. Если вы работаете под Windows (что вполне вероятно, раз уж вы используете TFS), тогда git-tfs будет наиболее разумным выбором, так как его функциональность наиболее полна; но если вы используете другую платформу, вам придётся использовать более ограниченный git-tf. Как и с большинством других описываемых в этой главе инструментов, вам следует выбрать единственный "источник правды": вы будете делиться наработками либо через Git, либо через TFVC, но никак не через обе системы сразу.

Если у вас уже есть кодовая база в другой СКВ, но вы решили начать использовать Git, вам необходимо так или иначе перенести миграцию проекта. В этом разделе описаны некоторые существующие варианты импорта для распространённых систем, а затем показано, как разрабатывать собственные нестандартные варианты импорта. Вы узнаете, как импортировать данные из некоторых распространённых профессиональных СКВ. Поскольку они используются большинством разработчиков, для них легко найти качественные инструменты миграции.

Если вы читали предыдущий раздел про использование git svn, вы уже должны знать, как использовать команду git svn clone чтобы склонировать Subversion репозиторий. После этого вы можете прекратить использовать Subversion и перейти на Git. Сразу же после клонирования вам будет доступная вся история репозитория, хотя сам процесс получения копии может затянуться.

В добавок к этому импортирование не идеально, так что вы, возможно, захотите сделать его как можно более правильно с первой попытки. И первая проблема — это информация об авторстве. В Subversion на каждого участника рабочего процесса заведён пользователь, информация о пользователе сохраняется вместе с каждой ревизией. В предыдущем разделе вы могли видеть пользователя schacon в некоторых местах, типа вывода команды blame или git svn log. Если вы хотите видеть подробную информацию об авторстве в Git, вам потребуется задать соответствие между пользователями Subversion и авторами в Git. Создайте файл users.txt со следующим содержимым:

schacon = Scott Chacon

selse = Someo Nelse

Чтобы получить список имён пользователей в SVN, выполните следующее:

$svn log --xml | grep author | sort -u | \

perl -pe 's/.*>(.*?)<.*/$1 = /'

Эта команда генерирует XML документ, оставляет только строчки с авторами, избавляется от дубликатов, а затем обрезает XML-теги. (Очевидно, она сработает только на компьютерах с установленными grep, sort и perl.) Вы можете направить вывод этой команды в файл users.txt, а затем просто дописать Git авторов в каждой строке.

Затем вы можете передать этот файл git svn, чтобы тот мог проассоциировать авторов. Также вы можете указать git svn не включать метаданные, обычно вставляемые в сообщения коммитов, передав флаг --no-metadata командам clone или init. Итого, команда import примет вид:

$git svn clone http://my-project.googlecode.com/svn/ \

--authors-file=users.txt --no-metadata -s my_project

Теперь у вас будет красивая копия Subversion репозитория в директории my_project. Вместо коммитов типа