Corregir la fusión de git 'hacia atrás' que se empujó

Me he encontrado con un problema entre mis twigs de git que no estoy seguro de cómo acercarme. Digamos que tengo twigs separadas para cada versión en la que estoy trabajando. Por ejemplo, tengo 'Release-1' y 'Release-2' como mis twigs. Estas versiones son de naturaleza secuencial, es decir, 'Release-2' contiene todo en 'Release-1', pero no al revés. En mi caso, accidentalmente fusioné 'Release-2' en 'Release-1' y lo empujé sin darme count de mi error. Uno me di count de que cometí un error, me presenté y emití:

git revert -m 1 <sha-of-bad-merge-commit> 

Esto pareció arreglar todo; ninguno del código 'Release-2' estaba en 'Release-1' y todo parecía correcto. Empujé esto hacia mi stream ascendente pensando que estaba resuelto. Avance rápido hasta hoy. He aplicado una corrección de error en la twig 'Release-1'. Ahora, quiero fusionar 'Release-1' en 'Release-2', pero me encuentro con conflits. Git cree que los cambios realizados en el reverso de antes deben fusionarse en 'Release-2'. Esencialmente, git quiere eliminar los cambios de 'Release-2' que accidentalmente se introdujeron en 'Release-1' de 'Release-2' cuando trato de fusionarme.

Intenté search una solución y no encontré ninguna. Lo más cerca que he encontrado se aplica a la fusión demasiado temprano, a la reversión, y luego a intentar fusionar nuevamente en una date posterior. La solución fue revertir la reversión y luego hacer la fusión nuevamente. No creo que funcione en este caso, porque eso volvería a introducir los cambios en 'Release-1' que no están destinados a estar en 'Release-1'.

Además de mirar a través de cada file afectado línea por línea para seleccionar el set correcto de cambios, ¿existe una buena manera de abordar esto? No quiero simplemente tomar los cambios de la twig 'Release-2' donde hay conflictos, ya que algunos de ellos podrían ser legítimos. Además, he considerado simplemente fusionarme en la twig de reparación de errores con 'Release-2', pero luego el problema probablemente vuelva a popup en el futuro. Me gustaría evitar que eso suceda.

Aquí hay un dibujo aproximado de la situación:

 (Release-2) ---A----B----C---x---x---------*D* \ / (Release-1) ---x----Y------M---x---^M----Z 

Supongamos que A, B y C son confirmaciones normales que deseo para 'Release-2'. La punta de 'Release-1' es Y y solo contiene el trabajo 'Release-1'. Commit 'M' es donde fusiono accidentalmente commit 'C' y confirmo 'Y' en la twig 'Release-1'. En algún momento, noto mi error y revertir la fusión (confirmar '^ M'). Commit 'Z' tiene mi revisión en él. En este punto, quiero fusionar 'Release-1' de nuevo en 'Release-2'. Hago esto y termino en 'D.' Aquí es donde tengo mi problema. Esencialmente, mi fusión en 'D' indica que quiere eliminar todos los cambios realizados en 'A', 'B' y 'C', que no quiero. Otros files aparecen como conflictos debido a la fusión revertir. Por ejemplo, algunos files que quiero en 'Release-2' fueron eliminados en 'Release-1' cuando hice la reversión. Ahora, en 'D', git me dice que hay un conflicto de fusión porque una twig borró el file y la otra modificó el file.

Si alguien tiene alguna sugerencia, agradecería mucho escucharla. ¡Gracias!

(Voy a referirme a tu ^M commit como Mrevert , ya que el carácter ^ tiene un significado especial en algunos de los commands siguientes).

Do git merge --abort para abandonar su bash de crear commit D

Como tiene una serie de confirmaciones x--Mrevert--Z , y necesita get cambios de x y Z , pero no de Mrevert , necesita un process de tres pasos:

  1. Use git merge Mrevert^ para get todos los cambios hasta el punto de Mrevert . (La syntax c^ significa "el padre de commit c ").
  2. Usa git merge -s ours Mrevert para decirle a git que los cambios de la confirmación de reversión ^M ya están en tu twig. -s ours our significa mantener nuestra versión (es decir, Release-2) del tree, sin molestarnos con ninguna "fusión" real.
  3. Usa git merge Z para fusionarte en los cambios de Z

Esto producirá un gráfico de compromiso como:

 (Release-2) ---A----B----C---x---x---M1-----M2------M3 \ / / / (Release-1) ---x----Y------M-------x---Mrevert----Z 

Si haces git diff M1 M2 , verás que M2 no realiza ningún cambio en Release-2.