¿Cuándo utilizarías las diferentes estrategias de combinación de git?

Desde la página man en gitmerge, hay una serie de estrategias de fusión que puede usar.

  • resolver : esto solo puede resolver dos encabezados (es decir, la twig actual y otra twig de la que extrajo) mediante el algorithm de combinación de 3 vías. Intenta detectar cuidadosamente las ambigüedades de fusión entrecruzadas y, en general, se considera seguro y rápido.

  • recursivo : esto solo puede resolver dos cabezas usando el algorithm de fusión de 3 vías. Cuando hay más de un antepasado común que se puede utilizar para la combinación de 3 vías, crea un tree combinado de antepasados ​​comunes y lo utiliza como tree de reference para la combinación de 3 vías. Se ha informado que esto da como resultado less conflictos de fusión sin causar confusiones erróneas mediante testings realizadas en compromisos de fusión reales tomados del historial de desarrollo del kernel de Linux 2.6. Además, esto puede detectar y manejar fusiones que implican cambios de nombre. Esta es la estrategia de combinación pnetworkingeterminada al tirar o fusionar una twig.

  • pulpo – Esto resuelve el caso de más de dos cabezas, pero se niega a hacer una fusión compleja que necesita una resolución manual. Está destinado principalmente a ser utilizado para agrupar encabezados de twig de tema juntos. Esta es la estrategia de combinación pnetworkingeterminada al tirar o fusionar más de una twig.

  • nuestro – Esto resuelve cualquier número de cabezas, pero el resultado de la fusión es siempre el jefe de twig actual. Está destinado a ser utilizado para replace el historial de desarrollo anterior de las twigs laterales.

  • subtree : esta es una estrategia recursiva modificada. Al fusionar los treees A y B, si B corresponde a un subtree de A, B primero se ajusta para que coincida con la estructura arbórea de A, en lugar de leer los treees en el mismo nivel. Este ajuste también se hace al tree ancestro común.

¿Cuándo debería especificar algo diferente al pnetworkingeterminado? ¿Para qué escenarios es mejor?

No estoy familiarizado con la resolución, pero utilicé los otros:

Recursivo

Recursive es el valor pnetworkingeterminado para las fusiones de avance rápido. Todos estamos familiarizados con eso.

Pulpo

He usado pulpo cuando tuve varios treees que necesitaban fusionarse. Ves esto en proyectos más grandes donde muchas twigs han tenido un desarrollo independiente y está todo listo para join en una sola cabeza.

Una twig de pulpo combina múltiples cabezas en una cometa, siempre que pueda hacerlo limpiamente.

Por ejemplo, imagina que tienes un proyecto que tiene un maestro y luego tres twigs para fusionar (llámalos a, b y c).

Una serie de fusiones recursivas se vería así (tenga en count que la primera fusión fue un avance rápido, ya que no forzó la recursión):

serie de fusiones recursivas

Sin embargo, una fusión de pulpo solo se vería así:

commit ae632e99ba0ccd0e9e06d09e8647659220d043b9 Merge: f51262e... c9ce629... aa0f25d... 

fusión del pulpo

La nuestra

La nuestra == Quiero atraer otra cabeza, pero descartar todos los cambios que introduce la cabeza.

Esto mantiene el historial de una twig sin ninguno de los efectos de la twig.

(Leer: ni siquiera se han analizado los cambios entre esas twigs. Las twigs simplemente se fusionaron y no se hace nada con los files. Si desea fusionarse en la otra twig y cada vez que aparece la pregunta "nuestra versión de file o su versión "puedes usar git merge -X ours )

Subtree

Subtree es útil cuando desea combinar en otro proyecto en un subdirectory de su proyecto actual. Es útil cuando tiene una biblioteca que no desea include como submodule.

En realidad, las únicas dos estrategias que le gustaría elegir son las nuestras si quiere abandonar los cambios introducidos por la twig, pero mantenga la twig en la historia, y el subtree si está fusionando el proyecto independiente en el subdirectory del superproyecto (como 'git-gui' en ' git 'repository).

la fusión del pulpo se usa automáticamente al fusionar más de dos twigs. la resolución está aquí principalmente por razones históricas, y para cuando se ve afectado por casos de esquina de estrategia de fusión recursiva .

Estrategia de fusión "Resolver" vs "Recursiva"

Recursive es la estrategia actual pnetworkingeterminada de dos cabezas, pero después de algunas búsquedas finalmente encontré algo de información sobre la estrategia de fusión "resolver".

Tomado de O'Reilly book Version Control with Git ( Amazon ) (parafraseado):

Originalmente, "resolver" era la estrategia pnetworkingeterminada para las fusiones de Git.

En situaciones de fusión entrecruzadas, donde hay más de una base de fusión posible, la estrategia de resolución funciona de la siguiente manera: elige una de las posibles bases de combinación y espera lo mejor. Esto en realidad no es tan malo como parece. A menudo resulta que los usuarios han estado trabajando en diferentes partes del código. En ese caso, Git detecta que está resurgiendo algunos cambios que ya están en su lugar y omite los cambios duplicates, evitando el conflicto. O bien, si estos son cambios leves que causan conflicto, al less el conflicto debería ser fácil de manejar para el desarrollador.

He fusionado treees con "resolución" que falló con la estrategia recursiva pnetworkingeterminada. Me estaba volviendo fatal: git write-tree failed to write a tree errores, y gracias a esta publicación en el blog ( espejo ) probé "-s resolve", que funcionó. Todavía no estoy muy seguro de por qué … pero creo que fue porque tuve cambios duplicates en ambos treees, y resolví "salteados" de forma adecuada.