¿Cómo se elimina una revisión específica en el historial de git?

Supongamos que su historial de git se ve así:

1 2 3 4 5

1–5 son revisiones separadas. Debe eliminar 3 mientras mantiene 1, 2, 4 y 5. ¿Cómo se puede hacer esto?

¿Existe un método eficiente cuando hay cientos de revisiones después de la que se eliminará?

Para combinar la revisión 3 y 4 en una sola revisión, puede usar git rebase. Si desea eliminar los cambios en la revisión 3, debe usar el comando de edición en el modo de rebase interactivo. Si desea combinar los cambios en una sola revisión, use squash.

He utilizado con éxito esta técnica de squash, pero nunca antes había necesitado eliminar una revisión. Con suerte, la documentación de git-rebase en "Splitting commits" debería darle una idea suficiente para resolverlo. (O alguien más podría saberlo).

De la documentación de git :

Comience con la confirmación más antigua que desea conservar tal cual:

git rebase -i <after-this-commit>

Se activará un editor con todos los commits en su rama actual (ignorando los commits de fusión), que vienen después del commit dado. Puede reordenar las confirmaciones de esta lista al contenido de su corazón, y puede eliminarlas. La lista se ve más o menos así:

elegir deadbee La línea de este commit
pick fa1afe1 La línea del próximo commit
...

Las descripciones en línea son puramente para su placer; git-rebase no los verá sino a los nombres de confirmación ("deadbee" y "fa1afe1" en este ejemplo), así que no elimine ni edite los nombres.

Al reemplazar el comando "pick" con el comando "edit", puede decirle a git-rebase que se detenga después de aplicar ese commit, para que pueda editar los archivos y / o el mensaje de commit, modificar el commit y continuar el rebase.

Si desea doblar dos o más commits en uno, reemplace el comando "pick" con "squash" para el segundo commit y el siguiente. Si los commits tenían diferentes autores, atribuirá el commit aplastado al autor del primer commit.

Según este comentario (y verifiqué que esto es cierto), la respuesta de rado está muy cerca, pero deja a git en un estado de cabeza separada. En cambio, elimine HEADy use esto para eliminar <commit-id>de la rama en la que se encuentra:

git rebase --onto <commit-id>^ <commit-id>

Aquí hay una manera de eliminar de forma no interactiva un específico <commit-id>, sabiendo solo <commit-id>lo que desea eliminar:

git rebase --onto <commit-id>^ <commit-id> HEAD

Como se señaló antes, git-rebase (1) es tu amigo. Asumiendo que los commits están en su masterrama, usted haría:

git rebase --onto master~3 master~2 master

Antes de:

1---2---3---4---5  master

Después:

1---2---4'---5' master

De git-rebase (1):

También se puede eliminar una serie de confirmaciones con rebase. Si tenemos la siguiente situación:

E---F---G---H---I---J  topicA

entonces el comando

git rebase --onto topicA~5 topicA~3 topicA

daría como resultado la eliminación de confirmaciones F y G:

E---H'---I'---J'  topicA

Esto es útil si F y G fueron defectuosos de alguna manera, o no deberían ser parte del tema A. Tenga en cuenta que el argumento para --onto y el parámetro pueden ser cualquier commit-ish válido.

Si todo lo que desea hacer es eliminar los cambios realizados en la revisión 3, es posible que desee utilizar git revert.

Git revert simplemente crea una nueva revisión con cambios que deshacen todos los cambios en la revisión que está revocando.

Lo que esto significa es que retiene información sobre la confirmación no deseada y la confirmación que elimina esos cambios.

Esto es probablemente mucho más amigable si es posible que alguien haya retirado de su repositorio mientras tanto, ya que la reversión es básicamente una confirmación estándar.

Todas las respuestas hasta ahora no abordan la preocupación final:

¿Existe un método eficiente cuando hay cientos de revisiones después de la que se eliminará?

Los pasos siguen, pero como referencia, supongamos el siguiente historial:

[master] -> [hundreds-of-commits-including-merges] -> [C] -> [R] -> [B]

C : commit solo siguiendo el commit que se eliminará (clean)

R : El compromiso a eliminar

B : commit justo antes del commit a eliminar (base)

Debido a la restricción de "cientos de revisiones", estoy asumiendo las siguientes condiciones previas:

1. hay un compromiso vergonzoso que desearías nunca haber existido
2. hay CERO confirmaciones posteriores que realmente dependen de esa confirmación embarazosa (cero conflictos al revertir)
3. no le importa que aparezca como el 'Comprador' de los cientos de confirmaciones que intervienen ('Autor' se conservará)
4. nunca has compartido el repositorio
   • o realmente tiene suficiente influencia sobre todas las personas que alguna vez han clonado la historia con ese compromiso para convencerlos de que usen su nueva historia
   • y que no se preocupan acerca de la reescritura de la historia

Este es un conjunto de restricciones bastante restrictivo, pero hay una respuesta interesante que realmente funciona en este caso de esquina.

Aquí están los pasos:

1. git branch base B
2. git branch remove-me R
3. git branch save
4. git rebase --preserve-merges --onto base remove-me

Si realmente no hay conflictos, esto debería proceder sin más interrupciones. Si hay conflictos, puede resolverlos rebase --continueo decidir vivir con la vergüenza y rebase --abort.

Ahora debería estar en mastereso ya no tiene commit R en él. La saverama apunta a donde estabas antes, en caso de que quieras conciliar.

Depende de usted cómo desea organizar la transferencia de todos los demás a su nuevo historial. Usted tendrá que estar familiarizado con stash, reset --hardy cherry-pick. Y puede eliminar las base, remove-mey savelas ramas

También aterricé en una situación similar. Use el rebase interactivo usando el comando a continuación y mientras selecciona, suelte la tercera confirmación.

git rebase -i remote/branch

Así que aquí está el escenario que enfrenté y cómo lo resolví.

[branch-a]

[Hundreds of commits] -> [R] -> [I]

Aquí Restá la confirmación que necesitaba eliminar, y Ies una confirmación única que viene despuésR

Hice un compromiso de reversión y los aplasté juntos

git revert [commit id of R]
git rebase -i HEAD~3

Durante el squash de rebase interactivo, los últimos 2 commits.

Las respuestas de rado y kareem no hacen nada por mí (solo aparece el mensaje "La rama actual está actualizada"). Posiblemente esto sucede porque el símbolo '^' no funciona en la consola de Windows. Sin embargo, de acuerdo con este comentario, reemplazar '^' por '~ 1' resuelve el problema.

git rebase --onto <commit-id>^ <commit-id>