git se compromete con todas las twigs

Si solucioné un error en un file en la twig branch_a , que debería aplicarse a todas las twigs. ¿Hay alguna manera de aplicar el cambio a todas las sucursales sin tener que pagar las sucursales de forma individual?

 git commit -m 'commit msg' # on branch a git checkout branch_b git cherry-pick branch_a git checkout branch_c git cherry-pick branch_a 

Lo que me gustaría tener es un git commit --to-all-branches que intente propagar los cambios a todas las twigs si es posible.

Editar

Para aclarar un poco mi situación, escribo código para problemas computacionales. A menudo termino en una situación en la que no está claro qué enfoque es el mejor para resolver un problema determinado. Entonces creo una twig. Estas twigs tienden a divergir y son más como tenedores. Sin embargo, para mantener todos los files en su lugar, solo uso un repository git con múltiples twigs. En la situación de un error relevante para todas las twigs / tenedores estaba buscando actualizar todas las twigs automáticamente.

No, o estrictamente hablando, "sí, pero es tanto trabajo de otra manera". Los nuevos commits siempre se agregan a "la twig actual", incluso si eso es un "HEAD separado" . (A continuación, mostraré una forma de hacerlo con el estado "HEAD separada", aunque si agrega commits a las sugerencias de bifurcación existentes, eso es más trabajo que solo consultarlas).

Asumiendo que tienes algo como esto:

 ABC <-- br1 \ DF <-- br2 \ / E \ G <-- br3 

y tiene alguna corrección X que se debe aplicar encima de C , F y G para dar:

 ABC-X1 <-- br1 \ D F-X2 <-- br2 \ / E \ G-X3 <-- br3 

(tenga en count que los 3 commit Xn son commits diferentes ya que tienen diferentes padres), luego debe agregar "patch X" para confirmar C , y luego agregar "patch X" para confirmar F , y luego agregar "patch X" para confirmar G .

Tenga en count que no hay garantía de que, por ejemplo, el cambio de C a X1 coincida exactamente con el cambio de F a X2 aquí. Puede build cualquiera de los tres compromisos Xn primero, de la manera habitual. Luego (como en tu pregunta) simplemente te mueves a las otras twigs y git cherry-pick para crear (y posiblemente resolver conflictos) las otras X -es. Pero debe estar "en" esas twigs para agregar commits a ellos, entonces:

 $ git checkout br1 ... make fix, "git add", "git commit" to create X1 $ git checkout br2 Switched to branch 'br2'. $ git cherry-pick br1 # take diff of `C`-vs-`X1`, apply to `F` to make `X2` ... etc 

Repita para todas las twigs a las que se debe copyr el parche (y, si es necesario, modifíquelas para que quepan en esa twig).


Hay alternativas para hacer esto. Por ejemplo, supongamos que la twig br1 está realmente bien, y lo que ha descubierto es que la confirmación E está rota y debe corregirse, lo que afecta a las confirmaciones F y G Supongamos además que, o bien nadie más ha cometido F y G , o está dispuesto a obligar a quienes tienen esos dos compromisos a hacer un montón de trabajo para recuperarse de lo que está a punto de hacer. En ese caso, puede verificar el compromiso D y hacer un nuevo compromiso, E' , que sale de D Vamos a dibujar el punto de partida, dejando de A a C Vamos a get el git checkout D (por su SHA-1, o equivalentemente con este gráfico, usando br2~2 para nombrarlo) para get un "HEAD separado" allí:

 D <-- HEAD | | F <-- br2 \ / E \ G <-- br3 

Ahora:

 $ git cherry-pick -n br2^ # make a copy of E but don't commit yet # edit to fix it $ git commit # make new commit E' that's fixed 

Una vez que la confirmación finaliza, tenemos esto (aún con el " HEAD separado"):

  E' <-- HEAD / | | D | | F <-- br2 \ / E \ G <-- br3 

Ahora podemos copyr commit F a F' :

 $ git cherry-pick br2 

dando:

  F' <-- HEAD / E' / | | D | | F <-- br2 \ / E \ G <-- br3 

Ahora estamos listos para hacer que br2 refiera al compromiso F' :

 $ git branch -f br2 HEAD 

dando:

  F' <-- HEAD, br2 / E' / | | D | | F [abandoned] \ / E \ G <-- br3 

(Esta es la parte "o estrictamente hablando" que escribí arriba: puede agregar confirmaciones a un repository, luego mover las tags de las twigs para que etiqueten las nuevas cadenas de compromiso, en lugar de las antiguas. Todas las asignaciones agregadas mueven HEAD : es solo que si HEAD es una reference a una twig, también mueven la twig un paso adelante mientras trabajas. Tener HEAD refiere a una twig es la forma "normal" de trabajar, pero puedes fingirla después de los hechos en "detached" HEAD "modo con git branch -f . En este caso, estoy haciendo eso para build el nuevo br2 sin usar un nombre de twig, luego mover el nombre de la twig a la nueva cadena de confirmaciones una vez que esté listo.)

Ahora tenemos que copyr G a G' , uniendo G' a E' . Estos son los pasos:

 $ git checkout br2^ # get back on E' as a detached HEAD [git says stuff here about moving the detached HEAD] $ git cherry-pick br3 # copy commit G $ git branch -f br3 HEAD # and move br3 label here 

(esto es lo que hicimos para copyr F a F' , más o less) dando:

  F' <-- br2 / E' / \ | G' <-- HEAD, br3 | D | | F [abandoned] \ / E \ G [abandoned] 

Una vez que hayas terminado, probablemente git checkout somebranch search una twig para volver a "estar en una twig" y lejos de este estado de "HEAD desconectada".

Como se señala en los comentarios, la necesidad de aplicar un parche es general (¿es una palabra?), Ya que esto sugiere que tal vez haya algún problema en todo el process. (Pero esto es lo que parece cuando se soluciona un "error del día cero" cuando se tienen muchos productos diferentes que comparten el código base con el error del día cero).

Esto no existe, porque cada fusión puede dar como resultado conflictos separados que requieren la intervención del usuario. Debería escribir un script para hacer lo que quiera.