git - remote - ¿Cómo revertir una confirmación de fusión que ya está empujada a una rama remota?
git push (10)
git revert <commit_hash>
solo no funcionará. -m
debe ser especificado, y estoy bastante confundido al respecto.
¿Alguien ha experimentado esto antes?
A veces, la forma más efectiva de retroceder es retroceder y reemplazar.
git log
Utilice el segundo hash de confirmación (hash completo, el que desea revertir, antes del error mencionado) y luego rebranche desde allí.
git checkout -b newbranch <HASH>
A continuación, elimine la rama antigua, copie la rama nueva en su lugar y reinicie desde allí.
git branch -D oldbranch
git checkout -b oldbranch newbranch
Si se ha transmitido, elimine la rama antigua de todos los repositorios, presione la rama rehacer al más central y bájela a todos.
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
Donde <commit-hash>
es el hash de confirmación de la combinación que desea revertir, y como se indica en la explicación de esta respuesta , -m 1
indica que desea revertir al árbol del primer padre antes de la fusión.
La línea git commit ...
esencialmente confirma tus cambios, mientras que la tercera línea hace públicos tus cambios empujándolos a la rama remota.
Ben le ha dicho cómo revertir una confirmación de fusión, pero es muy importante que se dé cuenta de que al hacerlo "declara que nunca deseará que los cambios de árbol se introduzcan en la fusión. Como resultado, las combinaciones posteriores solo traerán cambios de árboles introducidos por Las confirmaciones que no son ancestros de la combinación revertida previamente. Esto puede o no ser lo que quieres ". (página del manual de git-merge) .
Un kernel.org/pub/software/scm/git/docs/howto/… vinculado a la página del manual detalla los mecanismos y las consideraciones involucradas. Solo asegúrese de comprender que si revierte el compromiso de fusión, no puede volver a fusionar la rama más tarde y esperar que los mismos cambios regresen.
Como mencionó Ryan, git revert
podría dificultar la fusión en el futuro, por lo que git revert
puede no ser lo que quieres. Encontré que usar el git reset --hard <commit-hash-prior-to-merge>
es más útil aquí.
Una vez que haya hecho la parte de restablecimiento completo, puede forzar el empuje hacia la rama remota, es decir, git push -f <remote-name> <remote-branch-name>
, donde <remote-name>
suele denominarse origin
. Desde ese punto, puede volver a fusionar si lo desea.
Encontré que crear un parche inverso entre dos puntos finales conocidos y aplicar ese parche funcionaría. Esto supone que ha creado instantáneas (etiquetas) fuera de su rama maestra o incluso una copia de seguridad de su rama maestra, digamos master_bk_01012017.
Digamos que la rama de código que fusionaste en master fue mycodebranch.
- Maestro de salida.
- Cree un parche inverso binario completo entre el maestro y su copia de seguridad.
git diff --binary master..master_bk_01012017 > ~/myrevert.patch
- Compruebe su parche
git apply --check myrevert.patch
- Aplique el parche con la firma
git am --signoff < myrevert.patch
- Si necesita volver a introducir este código una vez que se haya corregido, deberá bifurcarse del maestro revertido y
git branch mycodebranch_fix
git checkout mycodebranch_fix
git branch mycodebranch_fix
git checkout mycodebranch_fix
- Aquí debe encontrar la clave SHA para revertir y revertir revertir
git revert [SHA]
- Ahora puede utilizar su mycodebranch_fix para solucionar los problemas, cometer y volver a combinar en el maestro una vez hecho.
La opción -m
especifica el número padre . Esto se debe a que una confirmació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 deshacer.
Cuando vea una confirmación de fusión en la salida del git log
de git log
, verá que sus padres aparecen en la línea que comienza con Merge
:
commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <[email protected]>
Date: Wed Aug 17 22:49:41 2011 +0100
Merge branch ''gh-pages''
Conflicts:
README
En esta situación, git revert 8f937c6 -m 1
obtendrá el árbol tal como estaba en 8989ee0
, y git revert -m 2
8989ee0
git revert -m 2
restablecerá el árbol como estaba en 7c6b236
.
Para comprender mejor las ID de los padres, puede ejecutar:
git log 8989ee0
y
git log 7c6b236
La respuesta correctamente marcada funcionó para mí, pero tuve que dedicar un tiempo para determinar qué está pasando ... Así que decidí agregar una respuesta con pasos simples y sencillos para casos como el mío ...
Digamos que tenemos las ramas A y B ... Combinaste la rama A en la rama B y presionaste la rama B a sí misma, así que ahora la combinación es parte de ella ... Pero quieres volver al último compromiso antes de la fusión. ¿tú lo haces?
- Vaya a su carpeta raíz de git (la carpeta del proyecto generalmente) y use el
git log
Verá el historial de confirmaciones recientes: las confirmaciones tienen propiedades de confirmación / autor / fecha, mientras que las fusiones también tienen una propiedad de combinación, por lo que las verá así:
commit: <commitHash> Merge: <parentHashA> <parentHashB> Author: <author> Date: <date>
Use
git log <parentHashA>
ygit log <parentHashB>
- verá los historiales de confirmación de esas ramas principales - las primeras confirmaciones en la lista son las más recientes- Tome el
<commitHash>
de la confirmación que desea, vaya a su carpeta raíz de git y usegit checkout -b <newBranchName> <commitHash>
- que creará una nueva rama a partir de la última confirmación que haya elegido antes de la fusión. Voila, listo!
Para mantener el registro limpio como no sucedió nada (con algunas desventajas con este enfoque (debido a push -f)):
git checkout <branch>
git reset --hard <commit-hash-before-merge>
git push -f origin HEAD:<remote-branch>
''commit-hash-before-merge'' viene del registro (git log) después de fusionar.
Puede seguir estos pasos para revertir el (los) compromiso (es) incorrecto (s) o para restablecer su sucursal remota para corregir HEAD / estado.
- pago de la rama remota a repo local.
git checkout development
copie el hash de confirmación (es decir, el ID de la confirmación inmediatamente antes de la confirmación incorrecta) del registro
git log -n5
salida:
commit 7cd42475d6f95f5896b6f02e902efab0b70e8038 "Fusionar rama ''cometer mal'' en ''desarrollo''"
commit f9a734f8f44b0b37ccea769b9a2fd774c0f0c012 "esto es un commit incorrecto"
commit 3779ab50e72908da92d2cfcd72256d7a09f446ba "este es el commit correcto"restablecer la rama al hash de confirmación copiado en el paso anterior
git reset <commit-hash> (ie 3779ab50e72908da92d2cfcd72256d7a09f446ba)
- ejecute el
git status
para mostrar todos los cambios que formaron parte de la confirmación incorrecta. - simplemente ejecute
git reset --hard
para revertir todos esos cambios. - forzar el empuje de su sucursal local a distancia y notar que su historial de confirmación está limpio como estaba antes de que se contaminara.
git push -f origin development
git revert -m 1 <merge-commit>