por Vali Shah

Como Desarrollador, muchos de nosotros tenemos que elegir entre la Mezcla y de Reajuste. Con todas las referencias que obtenemos de internet, todo el mundo cree que » no use Rebase, podría causar problemas graves.»Aquí explicaré qué son la fusión y la rebase, por qué deberías (y no deberías) usarlas, y cómo hacerlo.

Git Merge y git Rebase sirven para el mismo propósito. Están diseñados para integrar los 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 la comunidad de Git. Algunos creen que siempre debes rebase 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, correcciones de errores u otras razones, la fusión de confirmaciones cambia a otra ubicación., Para ser más específico, 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.,da2a4595a»>

Merge Master -> Feature branch

Pros

  • Simple y familiar
  • conserva el historial completo y el orden cronológico
  • mantiene el contexto de la rama

cons

  • El historial de Confirmaciones puede contaminarse con muchas confirmaciones de fusión
  • depurar usando git bisect puede volverse más difícil

cómo hacerlo

fusionar la rama maestra en la rama de características usando el checkout y merge comandos.,

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

esto creará un nuevo «merge commit» en la rama feature 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 único «parche».»Luego integra el parche en la rama de destino.

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

las Rebases 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

Rebase feature branch into master

pros

  • agiliza un historial potencialmente complejo
  • manipular un solo commit es fácil (p. ej.,
  • evita el «ruido» de las confirmaciones de fusión en los repositorios ocupados con ramas ocupadas
  • limpia las confirmaciones intermedias haciéndolas una única confirmación, lo que puede ser útil para los equipos de DevOps

Cons

  • aplastar la función hasta un puñado de confirmaciones puede ocultar el contexto
  • característica rama actualizada siempre
  • El cambio de base con ramas remotas requiere que fuerces el empuje., El mayor problema que enfrentan las personas es que fuerzan el push pero no han establecido el predeterminado de git push. Esto resulta en actualizaciones de todas las ramas que tienen el mismo nombre, tanto local como remotamente, y eso es terrible de tratar.

si rebase incorrectamente y reescribe involuntariamente el historial, puede provocar problemas graves, ¡así que asegúrese de saber lo que está haciendo!

cómo hacerlo

Rebase la rama feature en la rama master usando los siguientes comandos.,

$ git checkout feature$ git rebase master

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

Rebasing 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 Característica EN master.,

$ git checkout feature$ git rebase -i master

esto abrirá el editor listando todas las confirmaciones que están a punto de ser movidas.

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

esto define exactamente cómo se verá la rama después de que se realice la rebase. Al reordenar las entidades, puede hacer que el historial se vea como lo que quiera. Por ejemplo, puede utilizar los comandos como fixup, squash, edit etc, en lugar de pick.

Que usar

Así que, ¿qué 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 establecer sus políticas de rebase de Git vs. merge. Porque resulta que una estrategia de flujo de trabajo no es mejor que la otra. Depende de su equipo.

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

finalmente, las decisiones sobre la fusión y el rebasamiento 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 está diseñada alrededor de la organización de sus equipos.

¿qué recomiendo?

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

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

  • que está desarrollando localmente: si no ha compartido su trabajo con nadie más. En este punto, deberías preferir cambiar de base en lugar de fusionar para mantener tu historial ordenado. Si usted tiene su bifurcación personal del repositorio y que no se comparte con otros desarrolladores, está seguro de rebase incluso después de haber empujado a su rama.
  • Su código está listo para su revisión: ha creado una solicitud de extracción. Otros están revisando su trabajo y potencialmente lo están buscando en su bifurcación para su revisión local., En este punto, no debe cambiar la base de su trabajo. Deberías crear confirmaciones de ‘reelaboración’ y actualizar tu 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 ser integrada en la rama de destino. ¡Felicitaciones! Estás a punto de eliminar tu rama de características. Dado que otros desarrolladores no se fetch-merging en estos cambios a partir de este punto, esta es su oportunidad de sanear su historia., En este punto, puedes reescribir el historial y plegar 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 cuando la característica se graduó a master.

conclusión

espero que esta explicación haya dado algunas ideas sobre Git merge y git rebase. La estrategia Merge vs rebase siempre es discutible. Pero tal vez este artículo le ayudará a disipar sus dudas y le permitirá adoptar un enfoque que funcione para su equipo.