Close

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

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.

Ventana de consola
Material relacionado

Git log avanzado

Logotipo de Bitbucket
VER LA SOLUCIÓN

Aprende a usar Git con Bitbucket Cloud

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. Está diseñado para combinar el historial de ramas de función 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

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.

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
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 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-normalize

Desactiva la opción "renormalize". Esta acción anula 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.


Compartir este artículo

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.

Gente que colabora utilizando un muro lleno de herramientas

Blog de Bitbucket

Ilustración de Devops

Ruta de aprendizaje de DevOps

Demostraciones de funciones con expertos de Atlassian del Centro de demostraciones

Cómo funciona Bitbucket Cloud con Atlassian Open DevOps

Suscríbete para recibir el boletín de DevOps

Thank you for signing up