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

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. Вместо коммитов типа

commit 37efa680e8473b615de980fa935944215428a35a

Author: schacon

Date: Sun May 3 00:12:22 2009 +0000

fixed install - go to trunk

git-svn-id: https://my-project.googlecode.com/svn/trunk@94 4c93b258-373f-11de-

be05-5f7a86268029

вы получите следующее:

commit 03a8785f44c8ea5cdb0e8834b7c8e6c469be2ff2

Author: Scott Chacon

Date: Sun May 3 00:12:22 2009 +0000

fixed install - go to trunk

Теперь не только поле с информацией об авторстве выглядит лучше, но и git-svn-id не мозолит глаза.

Также вам следует немного "вычистить" репозиторий сразу после импорта. Во-первых, следует удалить ненужные ссылки, устанавливаемые git svn. Вначале переместим метки, чтобы они действительно стали метками, а не странными удалёнными ветками, а затем удалим остальное, сделав все ветки локальными.

Чтобы переместить метки, выполните следующие команды:

$cp -Rf .git/refs/remotes/origin/tags/* .git/refs/tags/

$rm -Rf .git/refs/remotes/origin/tags

Они берут все удалённые ветки, начинавшиеся с remotes/origin/tags/ и делают из них настоящие легковесные метки.

Далее, сделайте остальные ветки, начинающиеся с refs/remotes, локальными, выполнив следующее:

$cp -Rf .git/refs/remotes/* .git/refs/heads/

$rm -Rf .git/refs/remotes

Теперь все ветки и метки из Subversion стали настоящими Git ветками и метками соответственно. Последнее, что нужно сделать — это добавить ваш Git сервер в качестве удалённого репозитория и залить данные на него. Вот пример добавления удалённого репозитория:

$git remote add origin git@my-git-server:myrepository.git

Так как вы хотите отправить все ваши ветки и метки, выполите это:

$git push origin --all

Наконец, все ваши ветки и метки перенесены на Git сервер и облагорожены!

Из-за того что Mercurial и Git обладают похожей моделью ветвления, а также из-за того что Git несколько более гибок, перенос репозитория из Mercurial в Git довольно прост; можете использовать инструмент hg-fast-export, который можно найти здесь:

$git clone http://repo.or.cz/r/fast-export.git /tmp/fast-export

Первым делом нужно получить полную копию интересующего Mercurial репозитория:

$hg clone /tmp/hg-repo

Следующим шагом создадим файл соответствия авторов. Mercurial менее строг к данным об авторстве коммитов, так что придётся слегка навести порядок. Вот однострочник для bash, который сгенерирует заготовку:

$cd /tmp/hg-repo

$hg log | grep user: | sort | uniq | sed 's/user: *//' > ../authors

Пройдёт несколько секунд, в зависимости от размера репозитория, и вы получите файл /tmp/authors со следующим содержимым:

bob

bob@localhost

bob

bob jones company com>

Bob Jones

Joe Smith

В примере выше, один и тот же человек (Боб) вносил изменения под пятью различными именами, лишь одно из которых правильное, а одно и вовсе не соответствует формату Git. hg-fast-export позволяет быстро исправить ситуацию, добавив ={new name and email address} к каждой строке, которую мы хотим изменить; чтобы оставить имя как есть, просто удалите нужные строки. Если же все имена выглядят хорошо, этот файл и вовсе не потребуется. В нашем примере мы хотим чтобы данные выглядели так:

bob=Bob Jones

bob@localhost=Bob Jones

bob jones company com>=Bob Jones

bob =Bob Jones

Затем нужно создать Git репозиторий и запустить экспорт:

$git init /tmp/converted

$cd /tmp/converted

$/tmp/fast-export/hg-fast-export.sh -r /tmp/hg-repo -A /tmp/authors

Флаг -r указывает на подлежащий конвертации Mercurial репозиторий, а флаг -A задаёт файл с соответствиями между авторами. Скрипт пробегается по наборам изменений Mercurial и преобразует их в скрипт для fast-import в Git (мы поговорим об этом инструменте чуть позже). Процесс конвертации займёт некоторое время (хотя и намного меньше, чем при конвертации по сети), а мы пока можем наблюдать за подробным выводом в консоли: