`git svn rebase` vs` git rebase trunk`

Estoy trabajando en un proyecto que usa subversión para su repository. Debido a que necesito hacer algunos cambios que aún no pueden enviarse al server svn, comencé a usar git svn para poder hacer checkins locales. Mi configuration se ve así:

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

 *------------------ 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 comprometa a svn entre git svn fetch y git svn rebase , ¿ git svn rebase ejecuta en master básicamente igual que git rebase trunk run en master?

¿Hay un flujo de trabajo más sensato para usar? Parece que hay muchas twigs 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.

Nota, de git svn , como se detalla en " ¿Por qué se revierte el significado de" nuestro "y" suyo "con git-svn ":

 git svn rebase 

Esto obtiene revisiones del padre SVN del HEAD actual y rebases el trabajo actual (no confirmado a SVN) en su contra.

Por lo tanto, no necesita el git svn fetch antes de su git checkout master y git svn rebase , especialmente si solo realiza un seguimiento de trunk (parent of master ).


Segundo punto, el git svn dcommit crearía revisiones en SVN para cada nueva confirmación en el master , pero su flujo de trabajo no muestra ninguna confirmación nueva en el master , solo en el topic (que nunca se fusionó en el master )


El OP Sean McMillan comenta:

De acuerdo con los documentos, git svn dcommit sin una twig especificada empuja los commits en el HEAD actual, no solo en el master . Así que me comprometo con SVN desde mi sucursal, y luego git svn rebase en un git svn rebase en el master para recuperar los commits desde SVN. dcommited la twig del topic después de haber dcommited . ¿Esto no es kosher?

Él detalla que:

No puedo enviarlos 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 trunk master el mismo que git svn rebase en la twig principal? " Si es así, entonces no necesito cambiar constantemente mis twigs, solo para volver a establecer mi twig 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 respondo:

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