Я перешел на git с помощью git-svn. Наш репозиторий svn по-прежнему в рабочем состоянии, и мы по-прежнему получаем все "git awesomeness". По сути, после клона git-svn вы снова разветвляете его как свой «ствол». Отсюда все, кто использует git, ответят. Когда вам нужно получать обновления от svn, вы просто выполняете git-svn rebase, а затем git merge --squash из ветки svn в новый «ствол». И наоборот. Это будет означать, что ваша история в репозитории svn не будет соответствовать содержимому git. Когда вы выполняете более одного слияния, в какой-то момент вам придется начать прививать коммиты, потому что история не совпадает. Однако, если вы привяжете ГОЛОВУ своего ствола git к последнему идентификатору фиксации, который был сжатым слиянием, вы получите тот же эффект.
Хорошо, позвольте мне как можно лучше разобрать это на примере.
svn репо: svn: //xyz.com/myproject
git svn clone svn://xyz.com/myproject
Это должно оставить вас с нормальной настройкой git-svn с основной веткой, которая имеет ту же историю, что и репозиторий svn.
git checkout -b git_trunk
git_trunk становится «стволом» для пользователей git.
Эту ветку можно свободно использовать, как и любой другой репозиторий git.
Теперь вам нужно синхронизировать эти две ветки с помощью git merge --squash
Например .. слияние из ветки master svn на git_trunk
git checkout git_trunk
git merge --squash master
git commit -a
Вы бы сделали то же самое, чтобы выполнить слияние из git_trunk с главным svn, за исключением того, что вы выполнили бы
git svn dcommit
Это вернет его в svn.
Итак, сложность здесь в том, что, поскольку мы используем --squash, история слияния теряется, и единственный общий предок, о котором когда-либо будет знать git, - это точка ветвления. Это будет означать конфликты слияния. Я решил это, сделав что-то вроде этого
Слияние из git_trunk в master. Сначала я беру идентификатор последнего сквоша на git_trunk. Назовем это ABCDEFG. Затем я получаю фиксацию git_trunk. Допустим, это HIJKLMNO
echo "HIJKLMNO ABCDEFG" > .git/info/grafts
Это сообщит git при слиянии, что наиболее распространенным предком является последний скошенный коммит.
Это не идеально, но для меня это отлично работает. Особенно сейчас, когда почти все пользуются git.
person
Community
schedule
23.08.2009
