Confirmar un cambio en más de una sucursal en Git

Question

Escenario de uso típico:

Tengo master, branch_foo y branch_bar. Todos están actualizados. Ahora, hago un "maestro de pago de git" y trabajo en una corrección de errores.

Digamos que la corrección estaba en un archivo rastreado que está en el mismo estado en todas las ramas, es decir. antes de la corrección, una diferencia del archivo de cada rama no genera diferencias.

¿Hay alguna forma de aplicar esta solución a todas las sucursales?

Answer 1

Espero que git cherry-pick sea lo que quiere.

Después de confirmar la corrección a la primera rama, puede usar git cherry-pick para fusionarla en cada una de las otras ramas.

Esta pregunta relacionada sobre SO puede ser de interés: Git & Working on multiple branches

Answer 2

El enfoque común para esto es "fusionando hacia arriba". De man gitworkflows:

Siempre confíe sus correcciones a la rama más antigua compatible que lo requiera. Luego (periódicamente) fusiona las ramas de integración hacia arriba entre sí.

Esto proporciona un flujo muy controlado de arreglos. Si observa que ha aplicado una solución a, p. master que también se requiere en maint, tendrás que seleccionarlo con la mano (usando git-cherry-pick (1)) hacia abajo. Esto sucederá varias veces y no hay nada de qué preocuparse a menos que lo haga con mucha frecuencia.

Por supuesto, se prefiere el primer método: es bueno tener una confirmación en su repositorio solo una vez, y poder ver el historial de cómo llegó a cada rama. La vida no es perfecta, sin embargo, y a veces te encontrarás en la segunda categoría. Si esa situación llega a ser bastante común, tal vez podría escribir una secuencia de comandos como

multi-cherry-pick <commit> <branch> [<branch>...] 

que comprueba a cabo cada rama a su vez y cereza-escoge el commit dado.

Answer 3

Sí, la hay. Realice esta confirmación en rama de tema (función) separada (bifurcación de la rama más antigua/estado más antiguo), y luego combine esta rama de tema en cualquier rama que desee.

Este flujo de trabajo se describe, por ejemplo, en la publicación del blog Never merging back de Junio ​​C Hamano (responsable de mantenimiento de Git).

Eso es más o menos lo Jefromi wrote escribió