Git SVN Workflow - функция ветвей и слияния - PullRequest
Новая
       38

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

26 голосов
/ 15 июля 2009

Я сейчас использую 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». Это можно исправить с помощью merge fmt msg .

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

Ответы [ 4 ]

26 голосов
/ 15 июля 2009

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

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

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

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

4 голосов
/ 15 июля 2009

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

git checkout master
git merge --squash featureZ

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

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

2 голосов
/ 21 июля 2009

Ответ, заданный 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 it, либо git merge featuresZ

0 голосов
/ 18 июня 2012

Вместо 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 - это коммерческий продукт с некоторыми бесплатными опциями (открытые и академические проекты, небольшие команды).
...