Git fusionando hotfix en múltiples twigs

He estado tratando de entender a los models de ramificación de git. He estado buscando en http://nvie.com/posts/a-successful-git-branching-model/ algunas ideas y, viniendo de Subversion, una cosa que realmente estaba esperando era hacer un cambio en un solo lugar y uniéndolo a todas las twigs que lo necesitaban. En Subversion, terminamos haciendo mucha copy de código.

Sin embargo, todavía no entiendo esto por completo. Este es un tipo de flujo de trabajo estándar que tengo y siempre popupán conflictos.

# create new version branch git checkout master git checkout -b v3 vim pom.xml # change branch version to "3.1-SNAPSHOT" git commit -a git checkout master vim pom.xml # change master version to "4.0-SNAPSHOT" git commit -a 

Entonces el maestro está en 4.0-SNAPSHOT y la twig está en 3.1-SNAPSHOT.

No quiero crear una revisión en la twig y moverla al enlace.

 git checkout v3 git checkout -b hotfix vim file.txt # make a bugfix change git commit -a git checkout v3 git merge hotfix # this works fine git checkout master git merge hotfix # this has a conflict since both branches have changed the version 

Entiendo por qué está sucediendo y tiene sentido. ¿Hay una mejor manera de hacer esto?

Leí sobre cherry-pick, que probé y funciona:

 git checkout v3 git cherry-pick a518b0b75eaf28868 git checkout master git cherry-pick a518b0b75eaf28868 

Sin embargo, esa no parece ser la forma "correcta" de manejar esto. ¿Alguna sugerencia?

Realmente, tu respuesta depende de si quieres que tus treees se basen en el mismo historial … Por ejemplo, 4.0 se basa en el último 3.X + todos los cambios en 4.0 …

Personalmente, no lo recomiendo una vez que decida comenzar una nueva (s) sucursal (es) para una (s) nueva (s) versión (es). En un momento dado, el software está tomando una dirección diferente, por lo que sus twigs también deberían hacerlo.

Esto deja a git cherry-pick como su solución ideal. Haga el cambio en la twig que tenga más sentido, y luego selecciónelo con las versiones anteriores. Esto es lo mismo que si hubiera revisado la twig anterior y aplicara manualmente el mismo cambio, e hiciera una nueva confirmación. Lo mantiene limpio y al grano.

Git merge o rebase van a tratar de integrar el historial de sucursales juntas, cada una de ellas a su manera, lo que sospecho que no quieres cuando copyste las correcciones de errores, etc …

Si quería ser súper técnico al respecto, podría crear la revisión de un antecesor común:

 git merge-base v3 master git checkout -b hotfix <whatever you got from merge-base> # make your fix git checkout v3 && git merge --no-ff hotfix git checkout master && git merge --no-ff hotfix v3--------v3 (hotfixed) / / ancestor----hotfix \ \ master----master (hotfixed) 

El indicador --no-ff mantiene la label de bifurcación de la revisión en la sugerencia de la revisión, en lugar de llevar la label a v3 o master .

Personalmente, creo que es exagerado. Me gustaría ir con gahooa: hacer la revisión en la sucursal que tenga sentido, luego fusionarla o seleccionarla según la forma en que desee que las twigs se relacionen entre sí.

En el caso, está trabajando en la twig "4.0" y tiene que corregir "3.1", puede volver a establecer la base "4.0" después de confirmar "3.1":

 git checkout 4.0 # you are on the feature brnach 4.0 git stash # save current work so you can check out other branch git checkout 3.1 git commit -a -m "bug fix" # do editing and commit git checkout "4.0" git stash apply # get back your changes git rebase "3.1" # change 4.1 so it branches of the current head of "3.1" 

También he estado luchando con esta pregunta, y creo que si estás dispuesto a cambiar un poco tu estrategia de control de versiones (es decir, apartarse de las versiones -SNAPSHOT que Maven recomienda), esto podría resolverse usando una versión fija ( como SNAPSHOT o 0.0.0-SNAPSHOT) en el maestro (o cualquiera que sea su twig de desarrollo). (El sufijo SNAPSHOT es importante, si está usando Maven, ya que Maven trata los artefactos versionados con SNAPSHOT de forma diferente que otros).

De hecho, creo que desearía establecer una política de cambio constante del número de versión en su twig de producción (aquella desde la que crea versiones) o en sucursales que solo tienen fines de publicación (por ejemplo, cambiar los numbers de versión) y que nunca intentará fusionar de nuevo a la twig de desarrollo.

Todavía no he usado esta estrategia, pero solo estaba pensando en eso, y creo que empezaré a intentarlo.