`git svn rebase` kontra` git rebase trunk`

Question

Pracuję nad projektem, który wykorzystuje subversion do swojego repozytorium. Ponieważ muszę wprowadzić pewne zmiany, których nie można jeszcze przesłać na serwer svn, zacząłem używać git svn, aby móc wykonywać lokalne meldowanie. Moja konfiguracja wygląda następująco:

Odgałęzienia: tułów (śledzący pień svn), wzorzec (dość zbliżony do tego, co jest w svn) i temat.

*------------------ 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 

Zakładając, że nikt nie dopuszcza do svn między git svn fetch i git svn rebase, Czy git svn rebase bieg na pana w zasadzie taki sam jak git rebase trunk biegu na mistrza?

Czy istnieje rozsądniejszy przepływ pracy? Wygląda na to, że dzieje się wiele zmieniających się gałęzi i zmian. Rozumiem, że chcę móc dokonać reorganizacji mojej pracy nad wszystkim, co jest w svn, ale wydaje mi się, że robię więcej podstaw niż jest to absolutnie konieczne.

Answer 1

Uwaga, od git svn, jak wyszczególniono w "Why is the meaning of “ours” and “theirs” reversed with git-svn":

git svn rebase 

ten pobiera wersje z SVN rodzica obecnego szefa i rebases obecny (niezatwierdzone do SVN) działają przeciwko niej.

Więc nie potrzebne git svn fetch przed swój git checkout master i git svn rebase, zwłaszcza jeśli śledzić tylko trunk (rodzica master).

---

drugiego punktu, git svn dcommit stworzyłoby poprawki w SVN dla każdego nowego popełnić na master, ale przepływ pracy nie pokazuje każdy nowy popełnić na master tylko na topic (co nie zawsze jest połączone na master)

---

w OP Sean McMillan komentarze:

według Dokumenty, git svn dcommit bez Branc Podany parametr h popycha zatwierdzenia na bieżącej HEAD, a nie tylko na master. Dlatego zobowiązuję się do SVN z mojego oddziału, a następnie polegam na git svn rebase na master, aby przywrócić poprawki z SVN. Po otrzymaniu dcommited porzucam gałąź. Czy to nie jest koszerne?

On Wycinek że:

nie mogę wysłał je do SVN ... jeszcze. Upstream chce "zamrozić" bagażnik do wydania, tymczasem pracuję nad funkcjonalnością następnej wersji.

Ale ostateczny pytanie brzmi: „jest git rebase Mistrza bagażniku taka sama jak git svn rebase na gałęzi głównej?” Jeśli tak jest, to nie muszę być stale zmieniających swoje oddziały, żeby rebase mój główny oddział przeciwko SVN. Ale jeśli tak nie jest, i jakaś magia się dzieje, kiedy git svn rebase, chcę wiedzieć.

Na co odpowiada:

A git svn fetch następnie git rebase trunk master będzie równoważna git svn rebase.