Usar ramas

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 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 desee. 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.

Recursive

git merge -s recursive branch1 branch2

Esta 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 branch2

Esta 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 branchN

Se 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 branchN

Esta 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. Se ha diseñado para su uso en la combinación del historial de ramas de funciones similares.

Subtree

git merge -s subtree branchA branchB

Se 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

Mientras que las fusiones explícitas crean una confirmación de fusión, las implícitas, no. Una fusión implícita toma una serie de confirmaciones de un head de rama específico y las aplica a la parte superior de una rama de destino. Las fusiones implícitas se activan mediante eventos de reorganización o fusiones de avance rápido. Una fusión implícita es una selección ad hoc de confirmaciones de una rama específica.

Combinación al fusionar (normalmente, sin fusión explícita)

La combinación es otro tipo de fusión implícita. Se puede realizar una combinación durante una reorganización interactiva. Una fusión de combinación tomará las confirmaciones de una rama de destino y las combinará o les aplicará el comando squash en una sola confirmación. Dicha confirmación se añade al HEAD de la rama base de la fusión. Esta estrategia se suele usar para mantener un "historial limpio" durante una fusión. La rama de fusión de destino puede tener un historial detallado de confirmaciones frecuentes. Cuando se combinan y se fusionan, el historial de confirmaciones de las ramas de destino pasa a ser una "confirmación de rama" combinada singular. Esta técnica resulta útil con los flujos de trabajo de Git que utilizan ramas de función.

Opciones de la estrategia "recursive" de Git Merge

La estrategia "recursive" presentada anteriormente cuenta con su propio subconjunto de opciones de funcionamiento adicionales.

ours

No 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.

theirs

Se trata de la estrategia opuesta a "ours". La opción "theirs" favorece el árbol de fusión externa en la resolución del conflicto.

patience

Esta 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-algorithim

Esta opción permite especificar un algoritmo explícito de diferencia. Los algoritmos de diferencia son comunes a los del comando git diff.

ignore-*

    ignore-space-change
    ignore-all-space
    ignore-space-at-eol
    ignore-cr-at-eol

Un 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.

renormalize

Esta opción realiza comprobaciones de entrada y salida en los tres árboles de Git al resolver una fusión tripartita. Esta opción está diseñada para usarse en la fusión de ramas con estados de checkin/checkout diferentes.

no-normalize

Deshabilita la opción "renormalize". Sustituye la variable de configuración merge.renormalize.

no-renames

Esta opción ignorará los archivos a los que se les ha cambiado el nombre durante la fusión.

find-renames=n

Este 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 %.

subtree

Esta 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.

¿Listo para probar las ramas?

Prueba este tutorial interactivo.

Comienza ahora