`git svn rebase` vs` git rebase trunk` - программирование

Я работаю над проектом, который использует subversion для своего репозитория. Поскольку мне нужно внести некоторые изменения, которые не могут быть отправлены на сервер svn, я начал использовать git svn, чтобы я мог выполнять локальные проверки. Моя настройка выглядит так:

Филиалы: trunk (трекинг svn trunk), мастер (довольно близко к чему в svn) и тема.

*------------------ trunk
 \
  *-----------*--------- master
               \
                *-------- topic

Workflow:

[on branch master]
$ git svn fetch
$ git svn rebase
$ git checkout -b topic
$ git rebase master
[hack hack hack]
$ git commit -a
[once upstream is ready for my changes]
$ git svn fetch
$ git checkout master
$ git svn rebase
$ git checkout topic
$ git rebase master
$ git svn dcommit
$ git checkout master
$ git svn rebase
$ git branch -d topic

Предполагая, что никто не фиксирует svn между git svn fetch и git svn rebase, Выполняется ли git svn rebase на главном сервере так же, как git rebase trunk выполняется на master?

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

Ответ 1

Обратите внимание, из git svn, как указано в "Почему смысл "наши" и "их" обращены с помощью git -svn":

git svn rebase

Это выбирает ревизии родительского элемента SVN текущего HEAD и переустанавливает текущую (не совместимую с SVN) работу против него.

Поэтому вам не нужно git svn fetch перед вашими git checkout master и git svn rebase, особенно если вы отслеживаете только trunk (родительский элемент master).

Вторая точка, git svn dcommit создаст изменения в SVN для каждой новой фиксации на master, но ваш рабочий процесс не показывает никаких новых фиксаций на master, только на topic (который никогда не был слито на master)

Комментарий Шона Макмиллана:

В соответствии с документами git svn dcommit без указанной ветки посылает коммиты на текущий HEAD, а не только на master. Поэтому я передаю SVN из своей ветки, а затем полагаюсь на git svn rebase on master, чтобы вернуть коммиты из SVN. Я оставляю ветвь topic после того, как я dcommited. Это не кошерный?

Он уточняет, что:

Я не могу отправить их в SVN... пока. Upstream хочет "заморозить" туловище для выпуска, тем временем я работаю над функциональностью для следующей версии.

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

На что я отвечаю:

A git svn fetch, за которым следует a git rebase trunk master, будет эквивалентно a git svn rebase.