2012-06-15 9 views
8

He fusionado dos ramas. Tengo muchos conflictos. Resolvió a todos. Ahora no estoy seguro, tal vez cometí un error durante la resolución de conflictos. Y no veo otra forma de verificar si es cierto, simplemente ejecute fusionar de nuevo, y compruebe los conflictos uno por uno.git obtener conflictos de la fusión pasada sin ejecutar la fusión una vez más

Esto significa que necesito crear una rama más para almacenar los resultados de mi combinación, ¿verdad?

¿Lo puedo evitar? Quizás es posible obtener todos los archivos en conflicto con todos estos <<<<<<, ======, >>>>>> desde algún lugar en git, sin ejecutar fusionar una vez más?

+0

Quizás deberías aceptar una de las respuestas. – dotancohen

+0

No creo que las respuestas realmente respondan la pregunta. Las fusiones posteriores no deben mostrar los mismos conflictos de las fusiones anteriores. – e40

Respuesta

3

Si quieres ver lo que la fusión no se puede hacer

git show <hash-of-merge-commit> 

Si desea rehacer toda la combinación que hace

git checkout <branch-that-you-merged-to> 
git reset --hard <hash-of-the-commit-just-before-the-merge> 
git merge <branch-that-you-merged-in> 

Si desea rehacer la fusión y luego comparar la segunda mezcla para la primera fusión (para considerar si era mejor) que puede hacer:

git checkout <branch-that-you-merged-to> 
git rev-parse HEAD 

Esta elasticidad s usted el hash del compromiso actual. Anótelo. Después, realice

git reset --hard <hash-of-the-commit-just-before-the-merge> 
git merge <branch-that-you-merged-in> 

terminar la fusión, y luego hacer esto para comparar las fusiones

git difftool <hash-of-commit-noted-above> 

Si usted se sentía que la fusión original mejor, puede hacer

git reset --hard <hash-of-commit-noted-above> 
+0

Durante la combinación, puede jugar con "git show: 1: file.txt" para obtener la base de combinación, ": 2: file.txt" para mostrar el archivo de destino de combinación, ": 3: file.txt "para mostrar el archivo de fusión" –

2

Sí, es trivial En primer lugar, debe encontrar la identificación sha1 de la confirmación de fusión utilizando git log. Cuando haga lo siguiente:

git checkout <sha1>^1 
git merge <sha1>^2 

estará sin cabeza. ^n significa n-ésimo padre de una confirmación. Entonces, no se crean ramas. Puede resolver los conflictos nuevamente con más cuidado y luego

git diff HEAD..<sha1> 

para ver si hay diferencias en las resoluciones de conflictos.

Por cierto, bifurque en un git solo un nombre humano para un sha1 de compromiso, así que no tema crearlos tanto como desee.

PD: Si trabajas en Windows, ^ el símbolo en la línea de comandos es especial, necesitas duplicarlo o citar argumentos de líneas de comando.

Cuestiones relacionadas