git - tipos - ¿Administrar revisiones cuando la rama de desarrollo es muy diferente de la maestra?
¿para qué nos sirve el sha-1 cuando creamos tags? (3)
La forma más sencilla de obtener compromisos de una rama a otra es cherry-picking .
Asumiendo que tu solución en master tiene el hash de confirmación HASH y quieres llevar ese hotfix a tu rama de devel , haz un git checkout devel seguido de un git cherry-pick HASH . Eso es.
Si desea tomar todos los cambios de master en devel , puede lograrlo con
git checkout devel
git rebase master
Si tiene el escenario opuesto (realiza un hotfix durante el desarrollo en una rama de devel y desea convertir ese arreglo en master antes de que el devel se fusione completamente en el master ), el flujo de trabajo es bastante similar. Suponiendo que la revisión tiene el hash HOTFIX_HASH , haga esto:
git checkout master
git cherry-pick HOTFIX_HASH
Ahora, la confirmación está presente en master y devel . Para evitar esto, escriba
git checkout devel
git rebase master
y el compromiso desaparecerá del devel ya que ya está presente en el master .
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?
Mi flujo de trabajo general para esta situación es crear una rama de bug-fix de errores del master que corrige el problema. Una vez que esté listo, fusiona eso de nuevo en master 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 puedes probar una git merge -s ours master (ver man-page ) en develop para que la rama de 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 a partir de la etiqueta que necesita la solución, aplique la corrección y la versión, luego vuelvo a etiquetar y fusionar la nueva etiqueta en el master . Esto causa un conflicto debido a los números de versión, pero se puede evitar con el comando anterior.
Espero que ayude.
Normalmente sigo esta guide que se adapta bastante bien en la mayoría de los casos y evita al alcalde los problemas con conflictos y grandes cambios.
Si pudieras trabajar en ramas de feature y fusionarlas en development solo antes de la creación de una rama de release (lo que significa que estás preparando una versión) ... este método debería evitar la mayoría de los conflictos de fusión que experimentas.
Debido a que los cambios de ruptura ocurrirían en una sucursal para feature-breaking , PUEDE tener conflictos solo una vez en el momento en que esta rama de feature-breaking se fusiona en el desarrollo. Y también podría combinar el development en la rama de release en cualquier momento para mantenerlo actualizado.
También te encantará fusionar en el development todas las hotfix-branch que tengas con mínimo o sin conflictos.
La guía que compartí en el enlace anterior hace gran énfasis en nunca fusionarse del development al master o al revés. Siempre maneje sus lanzamientos a través de una rama de release .