Простое решение: удалить ветку 'work' после объединения
Краткий ответ: Вы можете использовать git так, как вам нравится (простой рабочий процесс см. Ниже), включая слияние. Просто убедитесь, что для удаления временной рабочей ветки следите за каждым ' git merge work ' с ' git branch -d work '.
Исходное объяснение:
Проблема слияния / dcommit состоит в том, что всякий раз, когда вы 'git svn dcommit' ветвь, история слияния этой ветки "сплющивается": git забывает обо всех операциях слияния, которые пошли в эту ветку: сохраняется только содержимое файла, но факт что этот контент (частично) пришел из определенной другой ветки, теряется. См .: Почему git svn dcommit теряет историю коммитов слияния для локальных веток?
(Примечание: git-svn мало что может с этим поделать: svn просто не понимает гораздо более мощных git-слияний. Поэтому в хранилище svn эта информация о слиянии не может быть представлена каким-либо образом.)
Но это проблема целом . Если вы удалите ветку 'work' после того, как она будет объединена с 'master веткой', то ваш репозиторий git будет на 100% чист и выглядит точно так же, как ваш svn-репозиторий.
Мой рабочий процесс:
Конечно, я сначала клонировал удаленный svn-репозиторий в локальный git-репозиторий (это может занять некоторое время):
$> git svn clone <svn-repository-url> <local-directory>
Затем вся работа происходит внутри "local-directory". Всякий раз, когда мне нужно получить обновления с сервера (например, 'svn update'), я делаю:
$> git checkout master
$> git svn rebase
Я делаю всю свою работу по разработке в отдельной ветке 'работа', которая создается так:
$> git checkout -b work
Конечно, вы можете создавать столько веток для своей работы, сколько захотите, а также объединять и перебазировать их между собой, как захотите (просто удалите их, когда закончите с ними - как описано ниже). В своей обычной работе я совершаю очень часто:
$> git commit -am '-- finished a little piece of work'
Следующий шаг (git rebase -i) является необязательным - это просто очистка истории перед ее архивированием на svn: Как только я достиг стабильного милиного камня, которым хочу поделиться с другими, я переписываю историю этого ветка 'работа' и очистка сообщений коммита (другим разработчикам не нужно видеть все маленькие шаги и ошибки, которые я сделал на пути - только результат). Для этого я делаю
$> git log
и скопируйте хэш sha-1 последнего коммита, который находится в репозитории svn (как указано в git-svn-id). Тогда я звоню
$> git rebase -i 74e4068360e34b2ccf0c5869703af458cde0cdcb
Просто вставьте хэш sha-1 нашего последнего коммита svn вместо моего. Вы можете прочитать документацию с помощью git help rebase для подробностей. Вкратце: эта команда сначала открывает редактор, представляющий ваши коммиты ---- просто измените 'pick' на 'squash' для всех тех коммитов, которые вы хотите раздавить с предыдущими коммитами. Конечно, первая строка должна оставаться в качестве «выбора». Таким образом, вы можете сконцентрировать ваши многочисленные маленькие коммиты в одну или несколько значимых единиц.
Сохраните и выйдите из редактора. Вы получите другой редактор с просьбой переписать сообщения журнала фиксации.
Короче говоря: после того, как я закончу «взлом кода», я массирую свою ветку «работа», пока она не увидит, как я хочу представить ее другим программистам (или как я хочу увидеть работу через несколько недель, когда просмотреть историю).
Чтобы отправить изменения в репозиторий svn, я делаю:
$> git checkout master
$> git svn rebase
Теперь мы вернулись к старой ветке 'master', обновленной со всеми изменениями, произошедшими за это время в репозитории svn (ваши новые изменения скрыты в ветке 'work').
Если есть изменения, которые могут конфликтовать с вашими новыми «рабочими» изменениями, вам нужно разрешить их локально, прежде чем вы сможете отправить свою новую работу (подробности см. Ниже). Затем мы можем отправить наши изменения в SVN:
$> git checkout master
$> git merge work # (1) merge your 'work' into 'master'
$> git branch -d work # (2) remove the work branch immediately after merging
$> git svn dcommit # (3) push your changes to the svn repository
Примечание 1. Команда 'git branch -d work' совершенно безопасна: она позволяет вам удалять только те ветки, которые вам больше не нужны (потому что они уже объединены с вашей текущей веткой). Если вы выполнили эту команду по ошибке до объединения вашей работы с веткой 'master', вы получите сообщение об ошибке.
Примечание 2: Обязательно удалите ветку с помощью 'git branch -d work' между merging и dcommit: если вы попытаетесь удалить ветку после dcommit, вы получите сообщение об ошибке: Когда вы делаете 'git svn dcommit', git забывает, что ваша ветка была объединена с 'master'. Вы должны удалить его с помощью 'git branch -D work', который не выполняет проверку безопасности.
Теперь я немедленно создаю новую ветку 'work', чтобы избежать случайного взлома ветки 'master':
$> git checkout -b work
$> git branch # show my branches:
master
* work
Интеграция вашей «работы» с изменениями в SVN:
Вот что я делаю, когда «git svn rebase» показывает, что другие изменили хранилище svn, когда я работал над моей веткой «работа»:
$> git checkout master
$> git svn rebase # 'svn pull' changes
$> git checkout work # go to my work
$> git checkout -b integration # make a copy of the branch
$> git merge master # integrate my changes with theirs
$> ... check/fix/debug ...
$> ... rewrite history with rebase -i if needed
$> git checkout master # try again to push my changes
$> git svn rebase # hopefully no further changes to merge
$> git merge integration # (1) merge your work with theirs
$> git branch -d work # (2) remove branches that are merged
$> git branch -d integration # (2) remove branches that are merged
$> git svn dcommit # (3) push your changes to the svn repository
Существуют более мощные решения:
Представленный рабочий процесс упрощен: он использует возможности git только в каждом раунде «update / hack / dcommit» - но оставляет долгосрочную историю проекта столь же линейной, как и хранилище svn. Это нормально, если вы просто хотите начать использовать git merges небольшими первыми шагами в старом проекте svn.
Когда вы познакомитесь с git merging, не стесняйтесь исследовать другие рабочие процессы: если вы знаете, что делаете, вы можете смешивать git merges с svn merges ( Использование git-svn ( или подобное) просто чтобы помочь с SVN слияния? )