Administrar las revisiones cuando la rama de desarrollo es muy diferente de la maestra?

Question

Estoy usando el modelo de ramificación "Git Flow", con una rama principal y una rama de desarrollo. Estoy trabajando en una nueva versión importante, por lo que mi rama de desarrollo es muy diferente de mi rama principal. Esto crea un problema cada vez que necesito hacer una revisión en la rama principal y fusionarla nuevamente en el desarrollo. Casi siempre hay conflictos, y se está convirtiendo en un verdadero dolor.

¿Cuál es la mejor manera de gestionar esto? Sería más fácil para mí hacer que los pequeños cambios de revisión se desarrollen manualmente y luego fusionar todo en maestro cuando esté listo sin fusionar el maestro de nuevo en desarrollo. es posible?

Answer 1

Mi flujo de trabajo general para esta situación es crear una rama bug-fix de master que soluciona el problema. Una vez que esté listo, combina eso de nuevo en master y luego combina master en develop.

Esto supone que la corrección de errores es casi uno a uno entre el código que necesita cambiar en ambas ramas. Si ese es el caso, siempre puede probar git merge -s ours master (vea man-page) en develop para que la rama develop tenga prioridad.

Utilizo un proceso similar para gestionar lanzamientos de solución de errores en un proyecto de código abierto en el que estoy trabajando. master siempre está por delante de donde se debe aplicar la corrección de errores, por lo que creo una rama de la etiqueta que necesita la solución, aplique la corrección y la versión, luego vuelva a etiquetar y fusionar la nueva etiqueta en master. Esto causa un conflicto debido a los números de versión, pero se puede evitar con el comando anterior.

Espero que ayude.

Answer 2

La forma más simple de obtener algunos commit de una rama a otra es cherry-picking.

Suponiendo que su arreglo en master tiene el hash HASH cometen y que desea tomar esa revisión en su sucursal devel, hacer un git checkout devel seguido de un git cherry-pick HASH. Eso es.

Si usted quiere tomar todos cambios de master en devel, se puede lograr que con

git checkout devel 
git rebase master 

---

Si usted tiene el escenario opuesto (que hacer una revisión durante el desarrollo en una rama devel y desea tomar esa corrección en master antes de que devel se fusione por completo en master), el flujo de trabajo es bastante similar. Suponiendo que la revisión tiene el hash HOTFIX_HASH, haga lo siguiente:

git checkout master 
git cherry-pick HOTFIX_HASH 

Ahora, la confirmación se presente en master y devel. Para evitar esto, el tipo

git checkout devel 
git rebase master 

y la confirmación desaparecerá de devel puesto que ya está presente en master.

Answer 3

Normalmente sigo este guide que se adapta bastante bien en la mayoría de los casos y evita alcalde de problemas con conflictos y grandes cambios.

Si se pudiera trabajar en feature ramas y fusionarlas en development únicamente antes de la creación de una rama release (lo que significa que en realidad se está preparando un lanzamiento) ... este método debe evitar la mayoría de los conflictos de fusión que experiencia.

Dado que los cambios de rotura se producirían en una rama feature-breaking, PUEDE tener conflictos solo una vez en el momento en que esta rama feature-breaking se fusione en el desarrollo. Y también puede combinar development en la sucursal release en cualquier momento para mantenerla actualizada.

También será bueno fusionarse en development todos los hotfix-branch que tiene con mínimo o ningún conflicto en absoluto.

La guía que compartí en el enlace anterior hace gran énfasis en nunca fusionar desde development hasta master o al revés. Siempre maneje sus lanzamientos a través de una sucursal release.