`git svn rebase` vs` git rebase trunk`

Question

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

багажник (отслеживание svn багажник), мастер (довольно близко к тому, что находится в 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 

Предположив, что никто не обязан СВН между git svn fetch и git svn rebase, ли git svn rebase работать на мастера в основном так же, как git rebase trunk работать на хозяина?

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

Answer 1

Примечание от git svn, как описано в "Why is the meaning of “ours” and “theirs” reversed with git-svn":

git svn rebase 

Это извлекает ревизию из SVN-родителя текущей ГОЛОВЫ и rebases тока (незавершенного к SVN) работать против него.

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

---

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

---

в OP Sean McMillan комментарии:

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

Он подробно, что:

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

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

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

А git svn fetch сопровождаемого git rebase trunk master бы эквивалентом git svn rebase.