Una introducción a Git merge and rebase: que son y como usarlos

Como desarrollador, muchos de nosotros tenemos que elegir entre Merge 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 fusionar y rebase, por qué debería (y no debería) usarlos y cómo hacerlo.

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

Esta pregunta ha dividido a la comunidad de Git. Algunos creen que siempre debes rebasar 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 utilizan sistemas de control de versiones. Ya sea que las ramas se creen para pruebas, corrección 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 de origen sigue siendo el mismo.

Pros

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

Contras

• El historial de confirmaciones puede verse contaminado por muchas confirmaciones de fusión
• La depuración con el uso git bisectpuede volverse más difícil

Cómo hacerlo

Fusionar la rama maestra en la rama de la característica usando los comandos checkouty merge.

$ git checkout feature $ git merge master (or) $ git merge master feature

Esto creará un nuevo " Merge commit " en la rama de funciones 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 el historial porque transfiere el trabajo completado de una rama a otra. En el proceso, se elimina el historial no deseado.

Las nuevas bases son cómo los cambios deben pasar desde la parte superior de la jerarquía hacia abajo, y las fusiones son cómo fluyen hacia arriba.

Pros

• Agiliza una historia potencialmente compleja
• Manipular una única confirmación es fácil (por ejemplo, revertirlos)
• Evita el "ruido" de fusión y confirmación en repositorios ocupados con sucursales ocupadas
• Limpia las confirmaciones intermedias convirtiéndolas en una única confirmación, 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 los repositorios públicos puede ser peligroso cuando se trabaja en equipo
• Es más trabajo: usar rebase para mantener su rama de características actualizada siempre
• Rebasar con ramas remotas requiere que fuerces el empuje. El mayor problema al que se enfrentan las personas es que fuerzan el push pero no han configurado git push por defecto. Esto da como resultado actualizaciones para todas las ramas que tienen el mismo nombre, tanto de forma local como remota, y es terrible tratar con eso .

Si reescribe el historial de forma incorrecta y sin querer, puede provocar problemas graves, ¡así que asegúrese de saber lo que está haciendo!

Cómo hacerlo

Vuelva a basar la rama de funciones en la rama maestra mediante los siguientes comandos.

$ git checkout feature $ git rebase master

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

Cambio de base interactivo

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

$ git checkout feature $ git rebase -i master

Esto abrirá el editor con una lista de todas las confirmaciones que están a punto de moverse.

pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3

Esto define exactamente cómo se verá la rama después de que se realice el rebase. Al reordenar las entidades, puede hacer que el historial tenga el aspecto que desee. Por ejemplo, puede utilizar comandos como fixup, squash, editetc., en lugar de pick.

Cual usar

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

Es difícil generalizar y decidirse por 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 fusión frente a rebase de Git. 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 el que valora la simplicidad del rebase en comparación con la trazabilidad y el historial de fusiones.

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

¿Qué recomiendo?

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

Al considerar las siguientes circunstancias y pautas, puede sacar el máximo provecho de Rebase:

• Se está desarrollando localmente: si no ha compartido su trabajo con nadie más. En este punto, debería preferir rebasar antes que fusionar para mantener su historial ordenado. Si tiene su bifurcación personal del repositorio y no se comparte con otros desarrolladores, puede volver a establecer la base de forma segura incluso después de haber pasado a su rama.
• Tu código está listo para su revisión: creaste una solicitud de extracción. Otros están revisando su trabajo y potencialmente lo están buscando en su bifurcación para revisión local. En este punto, no debe volver a basar su 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 rotura accidental del historial.
• La revisión está hecha y lista para integrarse en la rama de destino. ¡Felicidades! Estás a punto de eliminar tu rama de funciones. Dado que otros desarrolladores no se fusionarán con estos cambios a partir de este momento, esta es su oportunidad de desinfectar su historial. En este punto, puede reescribir el historial y doblar las confirmaciones originales y esas molestas confirmaciones de 'pr rework' y 'fusionar' en un pequeño conjunto de confirmaciones enfocadas. La creación de una combinación explícita para estas confirmaciones es opcional, pero tiene valor. Registra cuándo se graduó la función como maestra.

Conclusión

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

Estoy deseando escribir sobre flujos de trabajo de Git y conceptos de Git . Comenta los temas sobre los que quieres que escriba a continuación. ¡Salud!

code = coffee + developer

escuela de codificación para desarrolladores de software