Opciones y ejemplos de estrategias de Git Merge
Cuando se ha finalizado y probado un elemento de trabajo, y está listo para volver a fusionarse en la línea principal de desarrollo, tu equipo tiene que tomar algunas decisiones con respecto a la política. ¿Cuáles son las opciones de estrategia de fusión? En este artículo examinaremos las posibilidades y ofreceremos algunas notas sobre cómo funciona Atlassian. Esperamos que al acabar dispongas de las herramientas necesarias para decidir qué es lo más adecuado para tu equipo.
Estrategias de Git merge
La fusión se produce al combinarse dos ramas. Git tomará dos (o más) punteros de confirmación y tratará de encontrar una confirmación de base común entre ellos. Git cuenta con distintos métodos para encontrar una confirmación de base. A estos métodos se les denomina "estrategias de fusión". En cuanto Git encuentre una confirmación de base común, creará una nueva "confirmación de fusión" que combine los cambios de las confirmaciones de fusión especificadas. Técnicamente, una confirmación de fusión es una confirmación que tiene dos confirmaciones principales.
git merge seleccionará de forma automática una estrategia de fusión a menos que esta se especifique explícitamente. En los comandos git merge y git pull se puede utilizar una opción (estrategia) -s. La opción -s se puede adjuntar al nombre de la estrategia de fusión que quieras. Si no se especifica de forma explícita, Git seleccionará la estrategia de fusión más adecuada en función de las ramas proporcionadas. A continuación, encontrarás una lista de las estrategias de fusión disponibles.
Material relacionado
Git log avanzado
VER LA SOLUCIÓN
Aprende a usar Git con Bitbucket Cloud
Recursive
git merge -s recursive branch1 branch2Esta estrategia actúa en dos heads. Recursive es la estrategia de fusión predeterminada a la hora de incorporar cambios de una rama o fusionarla. Además, permite detectar y manejar fusiones que implican cambios de nombre, aunque actualmente no puede usar copias detectadas. Se trata de la estrategia de fusión predeterminada a la hora de incorporar cambios de una rama o fusionarla.
Resolución
git merge -s resolve branch1 branch2Esta estrategia solo permite resolver dos heads usando un algoritmo de fusión a 3 vías. Trata de detectar minuciosamente las ambigüedades de fusión entrecruzada y se la suele considerar una estrategia segura y rápida.
Octopus
git merge -s octopus branch1 branch2 branch3 branchNSe trata de la estrategia de fusión predeterminada para más de dos heads. Cuando te mueves por más de una rama, Octopus se activa automáticamente. Si una fusión tiene conflictos que requieren una resolución manual, Octopus rechazará el intento de fusión. Se utiliza principalmente para agrupar heads de rama de función similares.
Ours
git merge -s ours branch1 branch2 branchNEsta estrategia actúa en varios números N de ramas. El resultado de la fusión de salida es siempre el del HEAD de la rama actual. El término "ours" implica la preferencia ignorando efectivamente los cambios de todas las demás ramas. Está diseñado para combinar el historial de ramas de función similares.
Subtree
git merge -s subtree branchA branchBSe trata de una extensión de la estrategia recursiva. Al fusionar A y B, si B es un subárbol secundario de A, B se actualiza en primer lugar para reflejar la estructura de árbol de A. Esta actualización también se realiza en el árbol antecesor común compartido entre A y B.
Tipos de estrategias de Git Merge
Fusiones explícitas
Las fusiones explícitas son el tipo de fusión predeterminado. La parte "explícita" es que crean una nueva confirmación de fusión. Esto altera el historial de confirmaciones y muestra explícitamente la ubicación en la que se ha ejecutado la fusión. El contenido de confirmación de fusión también es explícito en el hecho de que muestra cuáles eran las confirmaciones principales en la confirmación de fusión. Algunos equipos evitan las fusiones explícitas porque podría decirse que las confirmaciones de fusión añaden "ruido" al historial del proyecto.
Fusión implícita mediante reorganización o fusión de avance rápido
Combinación al fusionar (normalmente, sin fusión explícita)
Opciones de la estrategia "recursive" de Git Merge
La estrategia "recursive" presentada anteriormente cuenta con su propio subconjunto de opciones de funcionamiento adicionales.
oursNo debe confundirse con la estrategia de fusión "ours". Al favorecer nuestra versión ("ours"), los conflictos no se resuelven automáticamente de forma correcta. Los cambios de la otra parte ("theirs") se incorporan automáticamente si no entran en conflicto.
theirsSe trata de la estrategia opuesta a "ours". La opción "theirs" favorece el árbol de fusión externa en la resolución del conflicto.
patienceEsta opción emplea más tiempo para evitar fusiones incorrectas en líneas coincidentes sin importancia. Esta opción se utilizará preferentemente cuando las ramas que se van a fusionar son muy divergentes.
diff-algorithimignore-*
ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eolUn conjunto de opciones que se dirigen a los caracteres de espacios en blanco. Se ignorará cualquier línea que coincida con el subconjunto de la opción usada.
renormalizeEsta opción realiza comprobaciones de registro y extracción en los tres árboles de Git mientras resuelve una fusión de tres vías. Esta opción está diseñada para usarse en la fusión de ramas con estados de checkin/checkout diferentes.
no-normalizeDesactiva la opción "renormalize". Esta acción anula la variable de configuración merge.renormalize.
no-renamesEsta opción ignorará los archivos a los que se les ha cambiado el nombre durante la fusión.
find-renames=nEste es el comportamiento predeterminado. La fusión "recursive" respetará los cambios de nombre de archivo. El parámetro n se puede usar para utilizar un umbral de similitud en el cambio de nombre. El valor predeterminado de n es 100%.
subtreeEsta opción se toma prestada de la estrategia "subtree". Mientras que la estrategia actúa en dos árboles y modifica cómo hacer que coincidan en un antecesor compartido, esta opción actúa en los metadatos de ruta del árbol para hacerlos coincidir.
Nuestra política de Git Merge
Atlassian prefiere utilizar fusiones explícitas. La razón es muy sencilla: las fusiones explícitas proporcionan una trazabilidad y un contexto excelentes de las funciones que se van a fusionar. Es muy recomendable realizar una reorganización de limpieza del historial local antes de compartir una rama de función para revisión, aunque esto no cambia la política en absoluto, sino que la mejora.
Compartir este artículo
Tema siguiente
Lecturas recomendadas
Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.
Blog de Bitbucket
Ruta de aprendizaje de DevOps
