git - remove - ¿para qué nos sirve el sha-1 cuando creamos tags?
¿Cuándo utilizarías las diferentes estrategias de combinación de git? (3)
Estrategia de fusión "Resolver" vs "Recursiva"
Recursiva es la estrategia de dos cabezas por defecto actual, pero después de algunas búsquedas finalmente encontré algo de información sobre la estrategia de fusión "resolver".
Tomado del libro O''Reilly, Version Control with Git ( Amazon ) (parafraseado):
Originalmente, "resolver" era la estrategia predeterminada para las fusiones de Git.
En situaciones de fusión cruzada, donde hay más de una base de fusión posible, la estrategia de resolución funciona así: elija una de las posibles bases de fusión y espere lo mejor. Esto no es realmente tan malo como suena. A menudo resulta que los usuarios han estado trabajando en diferentes partes del código. En ese caso, Git detecta que está fusionando algunos cambios que ya están en marcha y omite los cambios duplicados, evitando el conflicto. O, si estos son pequeños cambios que causan conflicto, al menos el conflicto debería ser fácil de manejar para el desarrollador.
He fusionado con éxito los árboles usando "resolver" que falló con la estrategia recursiva predeterminada. Me estaba volviendo fatal: git write-tree failed to write a tree errores de fatal: git write-tree failed to write a tree , y gracias a esta publicación del blog ( mirror ) intenté "-s resolver", que funcionó. Todavía no estoy exactamente seguro de por qué ... pero creo que fue porque tuve cambios duplicados en ambos árboles y resolví "omitirlos" correctamente.
Desde la página de manual de git-merge, hay una serie de estrategias de fusión que puede utilizar.
resolver : esto solo puede resolver dos cabezas (es decir, la rama actual y otra rama que extrajo) usando el algoritmo de combinación de 3 vías. Intenta detectar cuidadosamente las ambigüedades de fusión entrecruzada y se considera generalmente segura y rápida.
recursivo : esto solo puede resolver dos cabezas usando un algoritmo de combinación de 3 vías. Cuando hay más de un ancestro común que puede usarse para la combinación de 3 vías, crea un árbol combinado de los ancestros comunes y lo utiliza como el árbol de referencia para la combinación de 3 vías. Se ha informado que esto provoca menos conflictos de fusión sin causar fusiones erróneas por las pruebas realizadas en las confirmaciones de fusión reales tomadas del historial de desarrollo del kernel de Linux 2.6. Adicionalmente, esto puede detectar y manejar fusiones que involucran renombramientos. Esta es la estrategia de fusión predeterminada al extraer o fusionar una rama.
pulpo : esto resuelve más de dos cabezas, pero se niega a realizar una fusión compleja que necesita resolución manual. Está destinado principalmente para ser usado para agrupar los jefes de rama de tema juntos. Esta es la estrategia de fusión predeterminada al extraer o fusionar más de una rama.
nuestro - Esto resuelve cualquier número de cabezas, pero el resultado de la fusión es siempre la cabeza de rama actual. Está destinado a ser usado para reemplazar el antiguo historial de desarrollo de las ramas laterales.
Subárbol - Esta es una estrategia recursiva modificada. Al fusionar los árboles A y B, si B corresponde a un subárbol de A, B se ajusta primero para que coincida con la estructura de árbol de A, en lugar de leer los árboles al mismo nivel. Este ajuste también se hace al árbol de antepasado común.
¿Cuándo debo especificar algo diferente al predeterminado? ¿Qué escenarios son mejores para cada uno?
En realidad, las únicas dos estrategias que desearía elegir son las nuestras si quiere abandonar los cambios generados por la rama, pero mantenga la rama en el historial y subárbol si está fusionando un proyecto independiente en el subdirectorio del superproyecto (como ''git-gui'' en '''' repositorio de git).
Octopus Merge se usa automáticamente cuando se combinan más de dos ramas. La resolución está aquí principalmente por razones históricas, y para cuando se ven afectados por casos de esquinas de estrategia de combinación recursiva .
No estoy familiarizado con la resolución, pero he usado los otros:
Recursivo
Recursivo es el valor predeterminado para las fusiones que no son de avance rápido. Todos estamos familiarizados con eso.
Pulpo
He usado pulpo cuando he tenido varios árboles que debían fusionarse. Usted ve esto en proyectos más grandes donde muchas sucursales han tenido un desarrollo independiente y todo está listo para unirse en una sola cabeza.
Una rama de pulpo fusiona varias cabezas en un cometer siempre que pueda hacerlo limpiamente.
Para ilustrar, imagine que tiene un proyecto que tiene un maestro y luego tres ramas para fusionarlas (llámenlas a, b y c).
Una serie de fusiones recursivas se vería así (note que la primera fusión fue un avance rápido, ya que no forzé la recursión):
Sin embargo, una sola fusión de pulpo se vería así:
commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...
La nuestra
El nuestro == Quiero tirar de otra cabeza, pero desechar todos los cambios que la cabeza introduce.
Esto mantiene el historial de una rama sin ninguno de los efectos de la rama.
(Leer: Ni siquiera se miran los cambios entre esas ramas. Las ramas se fusionan y no se hace nada con los archivos. Si desea fusionarse en la otra rama y cada vez que aparezca la pregunta "nuestra versión de archivo o su version "puedes usar git merge -X ours )
Subárbol
El subárbol es útil cuando desea fusionar otro proyecto en un subdirectorio de su proyecto actual. Útil cuando tienes una biblioteca que no quieres incluir como submódulo.