remove - git rename tag
¿Son las fusiones simétricas en Git? (3)
Digamos que tenemos dos ramas ( B y C ) que se han separado de un ancestro común A. ¿La fusión de B a C producirá el mismo resultado que la fusión de C a B ?
A
|
/ /
B C
Para aclarar, asumo que cualquier resolución de conflicto de combinación manual ocurrirá en ambas direcciones. ¿Pero cualquier fusión automática que ocurra resultará en la elección del mismo código? Esto es lo que asumo, ya que las fechas 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 función de la dirección. Solo estoy preguntando por los conflictos resueltos automáticamente.
Depende de lo que quieras decir con el "mismo resultado". Desde la perspectiva del contenido, suponiendo que no haya conflictos o que todos los conflictos existentes se resuelvan meticulosamente exactamente de la misma manera, el contenido de la nueva combinación de resultados resultante debería 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 rama 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 ramas, aunque el contenido de la nueva confirmación sea idéntico en ambos casos.
La respuesta es sí para las fusiones predeterminadas. 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 orden. El tema de orden de fusión y conmutatividad generó una discusión fascinante en la lista 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 referencia en la pregunta.
Primero, la historia será diferente. Los padres del compromiso de fusión cambiarán dependiendo del orden 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 mezcla, 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 se invierten. E^1 es la punta de second_branch antes de la fusión. E^2 es la punta de first_branch.
En segundo lugar, se invertirá el orden de visualización de los conflictos. 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 fusión automática, pero aparecen cuando se invierte el orden de combinación de tres vías.
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 rama 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 resultará en la elección de C cambios. Aunque no estoy 100% seguro, así que puedes probarlo tú mismo y avisarnos.