2011-03-15 42 views
10

Tengo un repositorio con dos branches-- master y dev. Estaba trabajando en la rama principal y saqué, y recibí un mensaje de que el repositorio estaba actualizado. Cometí mis cambios, y empujé al repositorio remoto (en github). Recibí un mensaje que decía que algunos cambios fueron rechazados.revirtiendo push'd git commit

Luego hice un git pull origin dev, lo que al parecer fue lo incorrecto, ya que fusionó la rama de desarrollo con mi maestro, y como un idiota, no me di cuenta de esto hasta que ya había presionado nuevamente. Entonces, el último commit muestra Merge branch 'dev' of github.com:myuser/myrepo.

Puedo volver al último estado bueno conocido en mi repositorio local haciendo un git reset --hard [sha], siendo [sha] el compromiso antes de la fusión (aunque no estoy seguro de cómo hacer ese cambio en el origen) - o por lo que he leído, también puedo hacer un git revert -m y luego confirmar/presionar ese cambio.

¿Alguien puede guiarme por el "camino correcto" para deshacer mi fusión, y restablecer ambas ramas de nuevo a donde estaban antes de la fusión?

Gracias-- si es importante, este es un repositorio compartido con solo dos desarrolladores, por lo que no está sujeto a grandes cambios.

Editar para añadir: por favor hable conmigo como si fuera un niño. Tengo que admitir que estas cosas de Git todavía me confunden, ¡así que estoy lejos de ser un usuario poderoso! Gracias

Respuesta

20

El git reset --hard [sha] corregirá la sucursal en su repositorio local. Para forzar este impulso para que funcione, puede hacer un git push origin +master:master. El signo + forzará el empuje no lineal para que funcione.

Si los otros desarrolladores ya han retirado que mal comprometerse, van a tener que hacer un git remote update, a continuación, un git reset --hard origin/master (siempre que sean en su rama principal, y no han hecho ninguna otra confirmación.

Utilice estos comandos con cierta precaución :-). Buena suerte.

+0

Arriesgado, pero si solo hay dos desarrolladores, creo que está bien. Podría tener sentido hacer una copia de seguridad de al menos una copia de su repositorio antes de hacer esto, en caso de que lo arruine. –

+0

git push master de origen -f –

+0

gracias felipefg-- parece que funcionó a la perfección! Aprecio la respuesta clara. – julio

2

La respuesta de FelipeFG funciona bien en un contexto de dos desarrolladores donde puede coordinar fácilmente la reordenación del repositorio local del otro tipo, pero en realidad es mejor que use git revert -m<parent id of mainline branch, 1 in this case> <commit ref>. Luego, cuando haya terminado de arreglarlo, solo git revert <revert commit>, y git merge dev (es importante revertir su revertir para este caso, porque de lo contrario git merge dev no considerará que su combinación anterior es un antecesor, y esto dará lugar a conflictos que deben resolverse) .

La historia será fea, pero también será compatible con el reenvío rápido, y no tendrá que preocuparse por un poco de savia que desenrede un desastre de conflictos locales gracias a su revisión de historial.

Ver http://opensource.apple.com/source/Git/Git-26/src/git-htmldocs/howto/revert-a-faulty-merge.txt para más detalles.