¿Es posible reescribir el historial de una sucursal sin perder información de fusión en el camino?

Question

Tenemos una rama principal en la que hemos combinado aproximadamente 10 ramas de características, una a la vez.

Así que la historia reciente se parece a esto:

merged feat/10 (HEAD of master) 
merged feat/9 
merged feat/8 
merged feat/7 
merged feat/6 
merged feat/5 
... 

Ahora nos encontramos con que feat/7 era malo y queremos sacarlo del maestro. Revertir ese compromiso de fusión no es suficiente porque no queremos que ese compromiso roto exista en absoluto en nuestra historia. Realmente no podemos usar la base de datos interactiva porque eso aplanará el historial para que parezca que todo se hizo en una sola rama, y ​​queremos preservar todo ese buen historial de fusiones.

¿Hay alguna forma de borrar un merge commit de la historia de una sucursal?

Notaré que la historia real es mucho más compleja que la que ve en el ejemplo anterior, por lo que volver a realizar manualmente todas las fusiones ya que feat/7 no sería una buena opción.

Editar

para aclarar a los que votan para cerrar esto como un DUP: este no es el FAQ sobre la forma de llevar a cabo una confirmación usando rebase, que por supuesto ha sido contestada muchas veces. La pregunta aquí es acerca de sacar un commit sin aplanando el historial de fusión.

Answer 1

Si su historial actual se ve así y usted no eliminó las ramas aún puede simplemente git reset --hard HEAD~4 esto restablecerá su código de nuevo al estado antes de fusionarse en 7 entonces simplemente puede git merge las buenas de nuevo. Este es el más simple forma en que puedo pensar en mi cabeza.

EDIT: Puede utilizar -p interruptor de rebase para preservar fusiones pero utilizando este modificador con -i podría tener consequances. Compruebe la página man git-rebase y vea la parte BUGS para ver los errores actuales.

EDIT2: No asumo ninguna responsabilidad si no toma las precauciones adecuadas antes de usar este comando. No lo use antes de leer la página de manual también.

Answer 2

No se puede simplemente eliminar cosas de git porque el hash actual depende de todo el historial.

Una opción es crear una nueva rama que comience desde feat/6 y luego tenga las fusiones comenzando desde feat/8 para que el branch head pueda apuntar a un hash diferente sin los cambios de feat/7.

Otra opción, si no me equivoco, es git replace (creo que solía llamarse injertos). Puede permitirle "reemplazar" el puntero en feat/8 de feat/7 a feat/6. No estoy del todo seguro de cómo exactamente logra esto, pero parece que no es un verdadero reemplazo porque feat/8 aún tiene un puntero en alguna parte para feat/7 porque el hash no cambia, pero git replace de alguna manera agrega un historia alternativa en la que feat/8 puntos a feat/6. Desde el man page:

git replace [-f] <object> <replacement> 
git replace -d <object>… 
git replace -l [<pattern>] 

añade una referencia en reemplazar.git/refs/replace/

El nombre de la referencia de reemplazo es el SHA1 del objeto que es reemplazado. El contenido de la referencia de reemplazo es el SHA1 del objeto de reemplazo .

A menos que se especifique -f, la referencia de reemplazo aún no debe existir en .git/refs/replace/directory.

Las referencias de reemplazo se usarán de manera predeterminada por todos los comandos de git , excepto aquellos que realizan el recorrido de accesibilidad (podar, transferencia de paquetes y fsck).

Es posible deshabilitar el uso de referencias de reemplazo para cualquier comando usando la opción --no-replace-objects justo después de git.

EDITAR: en un segundo pensamiento git replace podría ser una mala idea ya que los cambios de feat/7 existirían en la fusión de feat/8. Probablemente debería ir con la primera opción: iniciar una nueva rama fuera de la hazaña fusionada/6 y remerge partir hazaña/8

Answer 3

Puede utilizar git filter-branch --parent-filter reescribir la feat/8 cometen de manera que sus puntos de origen ante la feat/6 comprometen . Dejar a los padres de todos los demás compromisos (9-10) tal como están, lo que debería preservar los compromisos de fusión en la historia tal como eran.

El único problema con esto es lo que sucederá con los conflictos que provoquen que se modifique el código eliminado ... no existe una forma real de saber, y podría ser el culpable.

Answer 4

Esto no es exactamente lo que quiere hacer ("zap" la fusión cometió, por así decirlo), pero en términos prácticos es la manera más fácil que convencer a sus colaboradores a git reset --hard después de un rebase o filter-branch. Solo revierte la fusión.

git revert -m 1 <commit_for_feat7> 

me gusta especialmente contaminantes mis ramas magistrales con revierte, pero no hay nada inherentemente malo en ello. Si no va a parchear feat7 por un tiempo, o simplemente quiere que sus conjuntos de cambios salgan de la historia, esta solución es mucho menos problemática que la revisión de la historia.