Pregunta ¿Cómo revertir una fusión que ya se envió a una sucursal remota?


git revert <commit_hash> solo no funcionará. -m debe ser especificado, y estoy bastante confundido al respecto.

Alguien experimentado esto antes?


531
2017-08-17 21:37


origen


Respuestas:


los -m la opción especifica el número de padre. Esto se debe a que una combinación de fusión tiene más de un padre y Git no sabe automáticamente qué padre era la línea principal y qué padre era la rama que desea desvincular.

Cuando ve una fusión se compromete en la salida de git log, verá a sus padres en la lista que comienza con Merge:

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <ben@example.com>
Date:   Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'

Conflicts:
    README

En esta situación, git revert 8f937c6 -m 1 te conseguirá el árbol como estaba en 8989ee0y git revert -m 2 restituirá el árbol como estaba en 7c6b236.

Para comprender mejor las ID principales, puede ejecutar:

git log 8989ee0 

y

git log 7c6b236

639
2017-08-17 21:53



Aquí hay un ejemplo completo con la esperanza de que ayude a alguien:

git revert -m 1 <commit-hash> 
git commit -m "Reverting the last commit which messed the repo."
git push -u origin master

Dónde <commit-hash> es el hash de confirmación de la fusión que le gustaría revertir, y como se indica en la explicación de esta respuesta, -m 1 indica que le gustaría volver al árbol del primer padre antes de la fusión.

los git commit ... línea compromete esencialmente sus cambios mientras que la tercera línea hace públicos sus cambios empujándolos a la rama remota.


240
2017-07-04 17:09



Ben te ha dicho cómo revertir un commit de fusión, pero es muy importante se da cuenta de que al hacerlo "declara que nunca querrá los cambios de árbol provocados por la fusión. Como resultado, las fusiones posteriores solo generarán cambios en el árbol introducidos por confirmaciones que no son ancestros de la fusión revertida anteriormente. no sea lo que quieras ". (página man git-merge).

Un artículo / mensaje de lista de correo enlazado desde la página del manual detalla los mecanismos y consideraciones que están involucrados. Solo asegúrese de comprender que si revierte la confirmación de fusión, no puede fusionar la rama más tarde y esperar que vuelvan los mismos cambios.


114
2017-08-18 01:23



Puede seguir estos pasos para revertir las confirmaciones incorrectas o restablecer su rama remota para corregir HEAD / state.

  1. checkout la sucursal remota al repositorio local.
    git checkout development
  2. copie el hash de confirmación (es decir, id de la confirmación inmediatamente antes de la confirmación incorrecta) desde el registro de git git log -n5

    salida:

    commit 7cd42475d6f95f5896b6f02e902efab0b70e8038 "Merge branch 'wrong-commit' en 'desarrollo'"
      commit f9a734f8f44b0b37ccea769b9a2fd774c0f0c012 "este es un commit incorrecto"
      cometer 3779ab50e72908da92d2cfcd72256d7a09f446ba "este es el compromiso correcto"

  3. restablecer la rama al hash de confirmación copiado en el paso anterior
    git reset <commit-hash> (i.e. 3779ab50e72908da92d2cfcd72256d7a09f446ba)

  4. ejecutar el git status para mostrar todos los cambios que fueron parte de la confirmación incorrecta.
  5. simplemente ejecuta git reset --hard para revertir todos esos cambios.
  6. fuerce-empuje su rama local a remoto y observe que su historial de compromiso está limpio como estaba antes de que se contaminara.
    git push -f origin development

45
2018-01-26 13:50



git revert -m 1 <merge-commit>

24
2017-09-27 14:03



A veces la forma más efectiva de deshacer es retroceder y reemplazar.

git log

Usa el 2º commit hash (hash completo, aquel al que deseas volver, antes de que aparezca el error) y luego vuelve a cambiar desde allí.

git checkout -b newbranch <HASH>

Luego borre la rama anterior, copie la nueva rama en su lugar y reinicie desde allí.

git branch -D oldbranch
git checkout -b oldbranch newbranch

Si se ha emitido, elimine la rama anterior de todos los repositorios, presione la rama redoneada a la más central y vuelva a colocarla en todos.


13
2018-06-14 18:23



Para mantener el registro limpio como no pasó nada (con algunas desventajas con este enfoque (debido a la inserción de -f)):

git checkout <branch>
git reset --hard <commit-hash-before-merge>
git push -f origin HEAD:<remote-branch>

'commit-hash-before-merge' proviene del registro (git log) después de la fusión.


8
2018-05-03 08:43



Encontré la creación de un parche inverso entre dos puntos finales conocidos y la aplicación de ese parche funcionaría. Esto supone que ha creado instantáneas (etiquetas) fuera de su rama principal o incluso una copia de seguridad de su rama principal, como master_bk_01012017.

Supongamos que la rama del código que fusionaste en el dominio era mycodebranch.

  1. Maestro de pago
  2. Cree un parche inverso binario completo entre el maestro y su copia de seguridad. git diff --binary master..master_bk_01012017 > ~/myrevert.patch
  3. Revisa tu parche git apply --check myrevert.patch
  4. Aplicar el parche con aprobación git am --signoff < myrevert.patch
  5. Si necesita volver a introducir este código una vez que se haya solucionado, deberá ramificar el maestro revertido y verificar la rama de reparación. git branch mycodebranch_fix git checkout mycodebranch_fix
  6. Aquí debe encontrar la clave SHA para revertir y revertir la reversión git revert [SHA]
  7. Ahora puede usar mycodebranch_fix para solucionar los problemas, confirmar y volver a fusionar en el maestro una vez hecho.

1
2018-02-24 15:57