`git svn rebase` vs` git rebase trunk`

Question

Estoy trabajando en un proyecto que usa subversion para su repositorio. Debido a que necesito hacer algunos cambios que aún no se pueden enviar al servidor svn, comencé a usar git svn para poder hacer comprobaciones locales. Mi configuración se ve así:

Sucursales: troncal (tracking svn trunk), master (muy cerca de lo que está en svn) y tema.

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

flujo de trabajo:

[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 

Suponiendo que nadie se compromete a svn entre git svn fetch y git svn rebase, Es git svn rebase corrida de maestro básicamente el mismo que git rebase trunk corrida de maestro?

¿Hay un flujo de trabajo más sensato para usar? Parece que hay muchas ramas cambiantes y que se está modificando. Entiendo que deseo poder rebasar mi trabajo además de lo que haya en svn, pero parece que estoy haciendo más rebases de los estrictamente necesarios.

Answer 1

Nota, desde git svn, como se detalla en "Why is the meaning of “ours” and “theirs” reversed with git-svn":

git svn rebase 

Esto obtiene las revisiones de los padres SVN del actual jefe y rebasa la corriente (no comprometidos a SVN) trabajan en contra de ella.

Así que no es necesario el git svn fetch antes de git checkout master y git svn rebase, sobre todo si la pista única trunk (padre de master).

---

Segundo punto, el git svn dcommit crearía revisiones en SVN para cada nuevo informe de cambios en master, pero el flujo de trabajo no muestra ningún nuevo commit en master, sólo en topic (que no está nunca se fusionó en master)

---

los OP Sean McMillan comentarios:

de acuerdo con los documentos, git svn dcommit sin branc h especificado empuja los commits en el HEAD actual, no solo en el master. Así que me comprometo con SVN desde mi sucursal, luego confío en git svn rebase en master para recuperar las confirmaciones de SVN. Abandono la rama topic después de que tengo dcommited. ¿Esto no es kosher?

Se detalla que:

yo no les puedo enviado a SVN ... todavía. Upstream quiere "congelar" el trunk para un lanzamiento, mientras tanto, estoy trabajando en la funcionalidad para la próxima versión.

Pero la pregunta final es, "es git rebase el tronco principal de la misma como svn git rebase en la rama principal?" Si lo es, entonces no necesito estar cambiando constantemente mis ramas, sólo para rebasar mi rama principal contra SVN. Pero si no es así, y hay algún tipo de magia sucediendo cuando gimo svn rebase, quiero saber.

A lo que contesto:

Un git svn fetch seguido de un git rebase trunk master sería el equivalente de un git svn rebase.