Una introducción a Git Merge y Git Rebase: qué hacen y cuándo usarlos

Como desarrollador, muchos de nosotros tenemos que elegir entre Fusionar y Rebase. Con todas las referencias que obtenemos de Internet, todos creen que "No use Rebase, podría causar serios problemas". Aquí explicaré qué son las fusiones y las rebajas, por qué debería (y no debería) usarlos, y cómo para hacerlo

Git Merge y Git Rebase tienen el mismo propósito. Están diseñados para integrar cambios de múltiples ramas en una sola. Aunque el objetivo final es el mismo, esos dos métodos lo logran de diferentes maneras, y es útil saber la diferencia a medida que te conviertes en un mejor desarrollador de software.

Esta pregunta ha dividido a la comunidad Git. Algunos creen que siempre debes rebajar y otros que siempre debes fusionar. Cada lado tiene algunos beneficios convincentes.

Git Merge

La fusión es una práctica común para los desarrolladores que usan sistemas de control de versiones. Si las ramas se crean para pruebas, correcciones de errores u otras razones, la fusión confirma los cambios en otra ubicación. Para ser más específicos, la fusión toma el contenido de una rama de origen y los integra con una rama de destino. En este proceso, solo se cambia la rama de destino. El historial de la rama fuente sigue siendo el mismo.

Fusionar maestro -> Rama de características

Pros

  • Simple y familiar
  • Conserva la historia completa y el orden cronológico.
  • Mantiene el contexto de la sucursal.

Contras

  • El historial de compromisos puede contaminarse con muchos compromisos de fusión
  • La depuración con git bisect puede ser más difícil

Cómo hacerlo

Combine la rama maestra en la rama característica utilizando los comandos de pago y fusión.

Función de pago de $ git
$ git merge master
(o)
Característica maestra $ git merge

Esto creará un nuevo "Compromiso de fusión" en la rama de características que contiene el historial de ambas ramas.

Git Rebase

Rebase es otra forma de integrar cambios de una rama a otra. Rebase comprime todos los cambios en un solo "parche". Luego integra el parche en la rama de destino.

A diferencia de la fusión, el rebase aplana la historia porque transfiere el trabajo completado de una rama a otra. En el proceso, se elimina la historia no deseada.

Las bases son cómo deben pasar los cambios desde la parte superior de la jerarquía hacia abajo, y las fusiones son cómo fluyen hacia arriba
Rebase de la rama de características en maestro

Pros

  • Agiliza una historia potencialmente compleja
  • Manipular una sola confirmación es fácil (por ejemplo, revertirlas)
  • Evita la fusión de "ruido" en repositorios ocupados con ramas ocupadas
  • Limpia los compromisos intermedios al hacerlos un solo compromiso, lo que puede ser útil para los equipos de DevOps

Contras

  • Reducir la función a un puñado de confirmaciones puede ocultar el contexto.
  • Rebasar repositorios públicos puede ser peligroso cuando se trabaja en equipo.
  • Es más trabajo: usar rebase para mantener actualizada la rama de características siempre
  • Rebasar con ramas remotas requiere que fuerces el empuje. El mayor problema que enfrentan las personas es que fuerzan el empuje, pero no han establecido el valor predeterminado de git push Esto da como resultado actualizaciones para todas las sucursales que tienen el mismo nombre, tanto local como remotamente, y eso es terrible de tratar.
Si reescribe incorrectamente y reescribe involuntariamente el historial, puede ocasionar problemas graves, ¡así que asegúrese de saber lo que está haciendo!

Cómo hacerlo

Rebase la rama de características en la rama maestra usando los siguientes comandos.

Función de pago de $ git
$ git rebase master

Esto mueve toda la rama de características encima de la rama maestra. Lo hace reescribiendo el historial del proyecto creando nuevas confirmaciones para cada confirmación en la rama original (característica).

Rebasamiento interactivo

Esto permite alterar las confirmaciones a medida que se mueven a la nueva rama. Esto es más poderoso que el rebase automático, ya que ofrece un control completo sobre el historial de confirmación de la sucursal. Por lo general, esto se usa para limpiar un historial desordenado antes de fusionar una rama de características en maestra.

Función de pago de $ git
$ git rebase -i master

Esto abrirá el editor al enumerar todas las confirmaciones que están a punto de moverse.

pick 22d6d7c Mensaje de confirmación n.º 1
pick 44e8a9b Mensaje de confirmación # 2
pick 79f1d2h Confirmar mensaje # 3

Esto define exactamente cómo se verá la rama después de realizar el rebase. Al reordenar las entidades, puede hacer que el historial se vea como lo desee. Por ejemplo, puede usar comandos como arreglar, aplastar, editar, etc., en lugar de elegir.

Cual usar

Entonces, ¿qué es lo mejor? ¿Qué recomiendan los expertos?

Es difícil generalizar y decidir sobre uno u otro, ya que cada equipo es diferente. Pero tenemos que empezar por alguna parte.

Los equipos deben considerar varias preguntas al configurar sus políticas de rebase de Git vs. fusión. Porque resulta que una estrategia de flujo de trabajo no es mejor que la otra. Depende de tu equipo.

Considere el nivel de rebase y competencia de Git en toda su organización. Determine el grado en que valora la simplicidad del rebase en comparación con la trazabilidad y el historial de fusión.

Finalmente, las decisiones sobre fusión y rebase deben considerarse en el contexto de una estrategia de ramificación clara (consulte este artículo para conocer más sobre la estrategia de ramificación). Se diseña una estrategia de ramificación exitosa en torno a la organización de sus equipos.

Que recomiendo?

A medida que el equipo crezca, será difícil administrar o rastrear los cambios de desarrollo con una política de fusión siempre. Para tener un historial de confirmación limpio y comprensible, usar Rebase es razonable y efectivo.

Al considerar las siguientes circunstancias y pautas, puede obtener lo mejor de Rebase:

  • Estás desarrollando localmente: si no has compartido tu trabajo con nadie más. En este punto, deberías preferir el rebase antes que la fusión para mantener ordenado tu historial. Si tiene su bifurcación personal del repositorio y eso no se comparte con otros desarrolladores, puede volver a crear una copia de seguridad incluso después de haber ingresado a su sucursal.
  • Su código está listo para su revisión: creó una solicitud de extracción. Otros están revisando su trabajo y potencialmente lo están llevando a su tenedor para su revisión local. En este punto, no debes rebajar tu trabajo. Debe crear confirmaciones de "retrabajo" y actualizar su rama de características. Esto ayuda con la trazabilidad en la solicitud de extracción y evita la ruptura accidental del historial.
  • La revisión está lista y lista para integrarse en la rama objetivo. ¡Felicidades! Estás a punto de eliminar tu rama de funciones. Dado que otros desarrolladores no se fusionarán en estos cambios a partir de ahora, esta es su oportunidad de desinfectar su historial. En este punto, puede reescribir el historial y doblar los commits originales y esos molestos 'pr rework' y 'merge' commits en un pequeño conjunto de commits enfocados. Crear una fusión explícita para estas confirmaciones es opcional, pero tiene valor. Registra cuándo la característica se graduó a maestra.

Conclusión

Espero que esta explicación haya dado algunas ideas sobre la fusión de Git y el rebase de Git. La estrategia de fusión vs rebase siempre es discutible. Pero quizás este artículo ayudará a disipar sus dudas y le permitirá adoptar un enfoque que funcione para su equipo.

Tengo muchas ganas de escribir sobre los flujos de trabajo de Git y los conceptos de Git. Comente sobre los temas sobre los que desea que escriba a continuación. ¡Salud!

código = café + desarrollador

Aquí hay otra referencia útil

  • Cómo adoptar una estrategia de ramificación de Git

escuela de codificación para desarrolladores de software