Простое решение: удалить ветку 'работа' после слияния
Краткий ответ: Вы можете использовать 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>
Вся работа происходит внутри «локального каталога». Всякий раз, когда мне нужно получить обновления с сервера (например, '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' между слиянием и dcommit: если вы попытаетесь удалить ветку после dcommit, вы получите сообщение об ошибке: Когда вы делаете 'git svn dcommit', git забывает, что ваша ветвь была объединена с 'master'. Вы должны удалить его с помощью 'git branch -D 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 merge? )