Git SVN Workflow - функции ветвления и слияния

Question

Я использую git-svn со следующим рабочим процессом

git clone <SVN TRUNK URL> #done once

впоследствии, когда я работаю над функцией

git branch featureZ
git checkout featureZ
#make edits for featureZ
git commit

git checkout master
git svn rebase # fetch changes from server

git checkout featureZ #go back to branch
#git merge master 
git rebase master #get the changes from SVN->master onto the branch now. Optional if I want the branch to be current. (EDITED: Got from the answer given below)

#make edits for featureZ
git commit #featureZ completed

git checkout master
git merge featureZ #getting featureZ onto master. Prepare to send to SVN

git svn dcommit #push featureZ back to SVN

Теперь некоторые моменты, когда я делаю git merge feature на master, все отдельные коммиты в ветви featureZ объединяются в один, что мне подходит.

Сообщение фиксации заменяется на "объединено с featureZ". Это можно исправить с помощью слияния fmt msg.

Теперь мой вопрос: есть ли что-нибудь, что может пойти не так с этим рабочим процессом или о котором нужно позаботиться. Я прочитал в руководстве git-svn, что слияние не должно выполняться при работе с git svn. Является ли то, что я делаю в своем рабочем процессе, к чему они относятся? если да, то какую проблему это вызовет? Во-первых, я не хочу делать что-то, что мешает магистрали SVN.

Answer 1

SVN не может обрабатывать нелинейную историю (она просто не имеет обозначений). Так что вы хотите сделать перебазирование вместо слияния, поскольку оно сохраняет линейную историю с SVN (это указано на странице руководства git-svn здесь.

Чтобы уточнить, линейные истории тривиальны. Они идут по прямой (от А до В до С до D). В то время как нелинейные истории могут переходить от (A к B к C, от B к D, затем к C + D к E- другими словами, они вырастают в ветви).

Перебазирование даст вам линейную историю. Помните, что ребаз должен быть сделан из ваших частных локальных филиалов. Например, если у вас есть 2 ветви: основная и экспериментальная. Вы должны проверить эксперимент и сделать 'git rebase master' предпочтительно с флагом -i. Это может привести к нежелательным побочным эффектам.

Тогда вы извлекаете мастер и объединяете изменения из экспериментальной ветки. Ваша история должна оставаться линейной.

Answer 2

Вы должны посмотреть на эту опцию слияния:

git checkout master
git merge --squash featureZ

Он объединит все коммиты на ветке в один коммит на ветке master. Вы получите возможность редактировать сообщение журнала, которое инициализируется с краткой информацией о том, что было сделано в ветке.

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

Answer 3

Ответ, заданный fake-code-monkey-rashid, является правильным. Это не просто ответ, а скорее упрощение.

Вы можете svn rebase/dcommit из любой ветки git. Единственное использование master будет иметь место, если у вас есть другие локальные изменения, которые вам необходимы для объединения с изменениями из featureZ.

git branch featureZ
git checkout featureZ
#bunch of changes
git commit
git svn rebase
# solve any conflicts
git svn dcommit

Если вы хотите сохранить чистый мастер, то вы можете либо git svn rebase это или git merge featuresZ

Answer 4

Вместо git-svn вы можете использовать SubGit. Это инструмент на стороне сервера, который автоматически синхронизирует репозитории Subversion и Git.

Вы можете использовать любой рабочий процесс Git и любой доступный клиент Git, дополнительные клиентские инструменты не требуются.

Учитывая ваш сценарий:

git branch featureZ
git checkout featureZ
# make edits for featureZ
git commit
git checkout master

Вы можете действовать следующим образом:

1. Нажмите на ветку функции полностью.

   git merge featureZ
   git push origin refs/heads/*
   

2. Перебазируем ветвь функции поверх мастер / ствол.

   git rebase featureZ
   git push
   

3. Сквош фиксируется из функциональной ветви.

   git merge --squash featureZ
   git commit
   git push
   

Как только вы отправляете изменения, перехватчики SubGit преобразуют ваши изменения в ревизии Subversion.

Еще несколько деталей:

• SubGit во многих отношениях превосходит git-svn - лучший перевод с отслеживанием слияний, поддержка EOL, MIME-типа и т. Д.
• SubGit необходим локальный доступ к хранилищу Subversion (он использует настраиваемые хуки);
• SubGit - это коммерческий продукт с некоторыми бесплатными опциями (open source и академические проекты, небольшие команды).