`git svn rebase` vs` git rebase trunk`

Question

Sto lavorando a un progetto che utilizza subversion per il loro repository. Poiché ho bisogno di apportare alcune modifiche che non possono ancora essere inviate al server svn, ho iniziato a utilizzare git svn in modo da poter eseguire checkin locali. La mia configurazione è la seguente:

Rami: tronco (tracciamento svn trunk), master (molto vicino a ciò che è in svn) e argomento.

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

flusso di lavoro:

[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 

Presumendo che nessuno si impegna a svn tra git svn fetch e git svn rebase, È git svn rebase corsa sul maestro fondamentalmente lo stesso come git rebase trunk corsa sul maestro?

C'è un flusso di lavoro più ragionevole da utilizzare? Sembra che ci sia un sacco di rami in cambiamento e di riforme in corso. Capisco che voglio essere in grado di rebase il mio lavoro sopra tutto ciò che è in svn, ma sembra che sto facendo più rebases di quanto strettamente necessario.

Answer 1

nota, da git svn, come dettagliato nella "Why is the meaning of “ours” and “theirs” reversed with git-svn":

git svn rebase 

Questo recupera revisioni dal genitore SVN della testa corrente e rebases la corrente (non impegnati a SVN) lavorare contro di esso.

Quindi non è necessario il git svn fetch prima git checkout master e git svn rebase, soprattutto se si traccia solo trunk (controllante di master).

---

Secondo punto, il git svn dcommit creerebbe revisioni SVN per ogni nuovo commit master, ma il flusso di lavoro non mostra alcun nuovo commit sul master, solo su topic (che non è mai incorporata il master)

---

i OP Sean McMillan commenti:

Secondo la documentazione, git svn dcommit senza branc h specificato spinge il commit sul corrente HEAD, non solo su master. Quindi mi impegno con SVN dalla mia filiale, quindi mi affido a un git svn rebase su master per riportare i commit da SVN. Abbandono il ramo topic dopo che ho dcommited. Non è kosher?

Ha dettagli che:

non posso li ho mandati a SVN ... ancora. Upstream vuole "congelare" il trunk per una release, nel frattempo sto lavorando sulle funzionalità per la prossima release.

Ma la domanda finale è: "è git rebase maestro tronco lo stesso di git svn rebase sul ramo padrone?" Se lo è, allora non ho bisogno di essere in continua evoluzione miei rami, solo per rebase il mio ramo principale contro SVN. Ma se non lo è, e c'è un qualche tipo di magia che accade quando faccio un svn rebase, voglio sapere.

Al che io rispondo:

Un git svn fetch seguito da un git rebase trunk master sarebbe l'equivalente di un git svn rebase.