2012-05-11 94 views
13

Supongamos que tenemos una rama de desarrollo 'A', y dos ramas secundarias 'B1' y 'B2', (ambas tomadas de A). Digamos que ejecuta un comando de código de formato (en nuestro caso, el código de limpieza de ReSharper) en todo el proyecto en B1 y B2.¿Cómo hacer que una operación de fusión de Git ignore los cambios idénticos realizados en ambas ramas?

Ahora, cuando intentemos unir B2 en B1, Git informará conflictos en todos los archivos en el proyecto (un número bastante grande en nuestro caso). Al mirar más de cerca cada conflicto, parece que Git piensa que hay un conflicto aunque se realizó el mismo cambio en B1 y B2 (?)

¿Hay alguna manera, un controlador/git personalizado, etc. que haga una ¿La operación de fusión de Git no informa un conflicto si los archivos en B1 y B2 son exactamente iguales?

Tal vez lo tengo mal, tal vez sea un problema de final de línea/blanco (por ejemplo, diferentes finales de línea en B1 y B2) en cuyo caso puedo encontrar la solución aquí en desbordamiento de pila.

+1

puede inspeccionar conflictos abriendo los archivos en un editor, podrá ver por qué git ve conflictos – CharlesB

+2

¿Cuánto trabajo aparte de la refactorización se realizó en estas ramas? No puedo hablar por Git específicamente, pero en general, que haría esto sólo en una rama, combinar los cambios a los padres, entonces tengo la segunda rama de recogida que refactorizar. – OrionRogue

+0

¿Intentó usar kdiff3 como mergetool en git? Por lo general, puede manejar esos conflictos triviales por sí mismo. – vhallac

Respuesta

1

Ayer tuve problema similar después de un montón de cereza-escoge a partir de (y para) una rama lateral en la que después se fusionó con mi rama principal. Una gran cantidad de conflictos con un cambio idéntico. Lo resolví con una estrategia de fusión:

git checkout main-branch 
merge --no-commit -s recursive -X ours side-branch 

puede cambiar "our" a "theirs". Tenga cuidado porque todos los conflictos se resuelven automáticamente eligiendo el lado "nuestro" o "suyos". En mi caso, tuve algunas confusiones debido a esto y lo arreglé manualmente. Vea otras opciones interesantes de estrategias de fusión aquí: https://www.kernel.org/pub/software/scm/git/docs/git-merge.html

También puede intentar usar una rebase (en mi caso no funcionó bien porque las ramificaciones eran demasiado diferentes y tuve un nuevo conflicto en cada nueva interacción de rebase). Ver esto: http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/

Cuestiones relacionadas