¿Las fusiones en Git son simétricas?

Digamos que tenemos dos twigs ( B y C ) que se han separado de un ancestro común A. ¿La fusión de B a C produce el mismo resultado que la fusión de C a B ?

A | / \ BC 

Para aclarar, asumo que cualquier resolución de conflicto de combinación manual ocurrirá en ambas direcciones. Pero, ¿se producirá alguna fusión automática que resulte en la elección del mismo código? Esto es lo que asumo, ya que las dates de confirmación son idénticas en ambas direcciones.

Para aclarar aún más: sé que la fusión real da como resultado "imágenes especulares" entre sí en function de la dirección. Solo estoy preguntando sobre los conflictos resueltos automáticamente.

La respuesta es sí para las fusiones pnetworkingeterminadas. Una fusión de tres vías encuentra un ancestro común y luego aplica las diferencias de ambos lados, una operación que no depende del order. El tema de order de fusión y conmutatividad generó una discusión fascinante en la list de git (si te gusta ese tipo de cosas, eso es). La nota B into C y C into B debe ser simétrica, pero no se puede decir lo mismo de (B into C) into A versus B into (C into A) .


Para elaborar un poco más, basado en el comentario de Vince a continuación y el comentario de Seh sobre la pregunta, habrá dos diferencias notables entre B into C y C into B , ninguno de los cuales afecta la resolución de fusión automática a la que se hace reference en la pregunta.

Primero, la historia será diferente. Los padres de commit de fusión cambiarán según la order de fusión. Para estos ejemplos, voy a usar "first_branch" y "second_branch", por lo que puedo reservar letras para representar commits.

 git checkout first_branch && git merge second_branch E <- merge commit |\ | D <- second_branch's tip | | | C <- another commit on second_branch | | | B <- and another |/ A <- first_branch's tip before the merge 

En este caso, el "primer padre" de E, E^1 , es la sugerencia de first_branch antes de la fusión. second_branch es el "segundo padre" del commit de fusión, también conocido como E^2 . Ahora considere lo contrario:

 git checkout second_branch && git merge first_branch E <- merge commit |\ | D <- first_branch's tip | | | C <- another commit on first_branch | | | B <- and another |/ A <- second_branch's tip before the merge 

Los padres son revertidos. E^1 es la punta de second_branch antes de la fusión. E^2 es la punta de first_branch.

En segundo lugar, el order de visualización de los conflictos se invertirá. En el primer caso, un conflicto podría verse así:

 <<<<<<< HEAD This line was added from the first_branch branch. ======= This line was added from the second_branch branch. >>>>>>> second_branch 

En el segundo caso, el mismo conflicto se vería así:

 <<<<<<< HEAD This line was added from the second_branch branch. ======= This line was added from the first_branch branch. >>>>>>> first_branch 

Ninguna de estas diferencias afecta a la resolución de combinación automática, pero sí aparece cuando invierte el order de fusión de tres vías.

Depende de lo que quiera decir con el "mismo resultado". Desde la perspectiva del contenido, suponiendo que no existen conflictos o que todos los conflictos existentes se resuelven meticulosamente de la misma manera, el contenido de la nueva confirmación de fusión resultante debe ser el mismo.

Sin embargo, desde el punto de vista de la topología de la historia, los dos son muy diferentes. Si está en la twig B y se fusiona en C, la CABEZA de B se mueve para apuntar a la confirmación de fusión, pero C se queda donde está. Por el contrario, si estás en C y te unes en B, HEAD de C se mueve, mientras que B se queda donde está. Por lo tanto, la topología final es muy diferente, lo que tiene implicaciones para el desarrollo futuro en cualquiera de las twigs, aunque el contenido de la nueva confirmación sea idéntico en ambos casos.

no, creo que no será simétrico Primero, puede establecer la opción de combinación de estrategia, particularmente en su caso, la theirs o la ours que determina si se elegirán B o C.

En las fusiones automáticas, creo que, por ejemplo, la twig remota tiene prioridad sobre sus cambios si se está fusionando con la suya, por lo que significa que llamar a git merge C desde B dará como resultado que se elijan C cambios. Aunque no estoy 100% seguro, así que puedes probarlo tú mismo y avisarnos.