git rebase en otra twig

dado el siguiente escenario:

  • Desarrollamos funciones en diferentes twigs temáticas.
  • Antes del lanzamiento, fusionamos todas las twigs de tema en master . La continuous integration luego comienza en esa twig
  • Además, también realizamos pequeños cambios (errores tipocharts, etc.) directamente en la twig principal
  • Si todo funciona bien, fusionamos todos los cambios desde la twig principal a la twig relase. Esta twig de lanzamiento será enviada

Este flujo de trabajo está bien siempre y cuando no haya nada de malo en nuestras testings. Pero tan pronto como decidimos no enviar una característica desde el maestro nos encontramos con problemas.

Por ejemplo:

  • Tenemos 5 twigs temáticas para diferentes características
  • Los fusionamos a todos en master
  • Además de eso, tenemos 2 confirmaciones separadas directamente en el maestro (corregimos algunos errores tipocharts)
  • Ahora descubrimos que 1 de las 5 características no funciona como se esperaba, no podemos enviarla
  • Todavía deseamos enviar las otras 4 funciones (+ las 2 confirmaciones hechas directamente en el maestro)

La única opción que tenemos ahora es: – fusionar las 4 twigs de tema directamente en el lanzamiento – cherry recoger las 2 confirmaciones en el maestro en la versión

Esto puede ser bastante molesto, especialmente cuando no hacemos un seguimiento de las confirmaciones hechas directamente en el maestro y el número aumenta.

Me gustaría tener un escenario en el que podamos:

  • ver todas las confirmaciones (o mejor: twigs fusionadas)
  • descartar todos los cambios que no queremos tener en la próxima versión
  • fusionar todos los otros cambios en la versión

Ya investigué un poco y me encontré con git rebase . El git rebase --interactive estuvo muy cerca de lo que esperaba.

El mejor escenario sería:

  • rebase todos los cambios desde el maestro a la versión interactiva
  • eliminar todos los commits (o mejores branches) que no necesito
  • lanzamiento solo tiene los cambios que quiero

El problema sin embargo es:

Cuando lo hago:

 git checkout master git rebase --interactive release <changes> 

Termino modificando la twig principal y no la twig de publicación. Agregar la opción de --onto release tampoco ayuda.

¿Existe la posibilidad de confirmar los resultados de rebase en otra twig?

respeta Leif

Mi comprensión del problema es que fusionas 5 twigs diferentes en master, y luego, antes de fusionarte en release, te das count de que uno de los 5 tiene errores, así que solo quieres mantener los otros 4.

Siendo este el caso, ¿por qué no git revert la git revert fusión de la twig defectuosa y continúas con el rest? ¿Se me escapa algo?

Para reference futura, eche un vistazo a Revertir una fusión defectuosa , que explica algunos escenarios para "deshacer" una combinación. Además, vea las advertencias en el manual de recuperación de Git Recuperación desde la database reutilizable y en Pro Git – Reescribiendo el historial . Y si aún no lo ha hecho, eche un vistazo al flujo de trabajo del proyecto Git y al exitoso model de ramificación de Git .

Un mejor flujo de trabajo en el futuro podría ser fusionar twigs de características en una twig de liberación y fusionar la twig de publicación en master después de que haya pasado la testing, QA, aceptación del usuario, etc. Normalmente espero hacer esta fusión justo antes de la date de lanzamiento. Siempre puede realizar una fusión de testing antes de la date de lanzamiento para asegurarse de que no haya sorpresas de conflicto de fusión.

Para solucionar su situación actual, supongamos que tenemos el siguiente historial con dos confirmaciones de arreglos y cinco confirmaciones de fusión de twigs de características:

 $ git --no-pager log --oneline --decorate --all --graph * e202262 (HEAD, master) Merge branch 'f5' |\ | * d9930ca (f5) f5 * | f9d743b Merge branch 'f4' |\ \ | * | eea7737 (f4) f4 | |/ * | c84ad9f Merge branch 'f3' |\ \ | * | 135c7f7 (f3) f3 | |/ * | 65ed393 Merge branch 'f2' |\ \ | * | 9a9b5b6 (f2) f2 | |/ * | 76ae0e8 Merge branch 'f1' |\ \ | * | 8a02982 (f1) f1 | |/ * | ace81a9 fix 2 * | d4b32e1 fix 1 |/ * ab6d5b0 A 

Lo que yo haría es:

  1. reset master a la confirmación ab6d5b0 .
  2. Crea una twig de release .
  3. Agregue la fix 1 y fix 2 confirmaciones a la twig de publicación.
  4. Asumiendo que f2 es la característica problemática, f5 twigs f1 , f3 , f4 y f5 en la twig de release .
  5. Mientras se están realizando las testings, realice una fusión de release en seco al master .
  6. Si todo está bien, fusione la release en el master .

Estos son los commands que se ejecutarían, utilizando el historial anterior, para llevar a cabo estos pasos (consulte el manual de reference de Git para get más información sobre estos commands):

 # Reset master to before the fix and merge commits git checkout master git reset --hard ab6d5b0 # Create a release branch git checkout -b release # Add the fix commits back git cherry-pick d4b32e1 git cherry-pick ace81a9 # Merge feature branches git merge f1 git merge f3 git merge f4 git merge f5 # Dry run merge git checkout master git merge --no-ff --no-commit release git reset --hard HEAD # Merge release to master git checkout master git merge --no-ff release 

Esto te dejará con la siguiente historia:

 $ git --no-pager log --oneline --decorate --all --graph * e24c16e (HEAD, master) Merge branch 'release' |\ | * d23369a (release) Merge branch 'f5' into release | |\ | | * d9930ca (f5) f5 | |/ |/| | * 8b90602 Merge branch 'f4' into release | |\ | | * eea7737 (f4) f4 | |/ |/| | * 926c094 Merge branch 'f3' into release | |\ | | * 135c7f7 (f3) f3 | |/ |/| | * e964e13 Merge branch 'f1' into release | |\ | | * 8a02982 (f1) f1 | |/ |/| | * bb5f6f5 fix 2 | * e8ffeef fix 1 |/ | * 9a9b5b6 (f2) f2 |/ * ab6d5b0 A 

Debido a que la preparación de la versión se realiza en una twig separada, la master permanece limpia y se pueden mitigar los dolores de cabeza debido a la selección de características.