Diferencia entre Git ReBase vs Merge
En este artículo, discutiremos dos herramientas de este tipo, Rebase y Merge, y sus diferencias. GIT es uno de los controladores de versión distribuidos DVCS más utilizados entre los programadores debido a su naturaleza dinámica y a la gran disponibilidad de herramientas para manejar las versiones. Hay dos formas con las que podemos enviar nuestros cambios de una rama a otra. Uno es mediante el uso de Rebase y el otro es Merge, que es bastante popular. A continuación, aprendemos la mejor comparación entre Git ReBase vs Merge.
Comparación cabeza a cabeza entre Git ReBase vs Merge (Infografía)
A continuación se presentan las 5 principales comparaciones entre Git ReBase vs Merge:
Diferencias clave entre Git ReBase y Merge
Analicemos la diferencia clave entre Git ReBase y Merge:
1. Git Rebase
Git Rebase comienza su trabajo a partir de un compromiso común entre las dos ramas. Maestro y característica, desde aquí compara ambos y captura la instantánea de la diferencia que se hace en una de las ramas y luego la agrega a otras. Veamos esto con las siguientes capturas de pantalla.
Imaginemos que tenemos una rama maestra y el último compromiso con ella m2 como se muestra en la captura de pantalla anterior. A partir de esta confirmación, creamos una rama de características e hicimos algunas modificaciones y confirmamos con el mensaje f1. Ahora consideremos que alguien ha fusionado su trabajo para dominar y ahora la última confirmación del maestro es m3, no m2 como se muestra a continuación.
Y también continuamos trabajando en la rama de características para agregar su último commit para ser f2 como se muestra a continuación.
Como se ve en la captura de pantalla anterior, hemos dominado el último commit m3 y tenemos una función que no está actualizada con el maestro, ya que se creó a partir de la instantánea de commit m2 que tiene el último commit como f3. Ahora para combinar estos esfuerzos con el maestro para generar se muestra a continuación.
Ahora necesitamos integrar los cambios anteriores que se pueden hacer de dos maneras, una con fusión y otra con rebase. Aquí veremos cómo integrarse con rebase.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
Desde el comando rebase anterior intentaremos buscar una confirmación común tanto del maestro como de la función y, en este caso, es m2. Y luego, dado que tenemos que volver a crear el maestro, buscará las adiciones que se hicieron con el maestro y tomará la instantánea m3 y la función de rebase de m2 a m3. Así que ahora tenemos una característica con m3 (en lugar de m2), f1, f2 commits. Ahora puedo solicitar un rebase en la función para actualizar la rama maestra con los cambios de la función. Una cosa para recordar es que cualquier cambio al maestro debe ser auditado. Aquí solo estoy mostrando, por ejemplo, propósito.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
Ahora en esto, aplicaremos la última rama de la función de confirmación que es f2 al maestro y la última instantánea de confirmación del maestro será f2. Puede enumerar las confirmaciones utilizando el comando git log, pero primero debemos verificar en qué rama necesitamos ver el registro como se muestra a continuación.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Ahora con rebase, hemos integrado las actualizaciones de una función para dominar. Intentemos lograr esto mediante la fusión.
2. Git Merge
También usaremos la captura de pantalla anterior para la referencia aquí, y también podemos lograr lo mismo que logramos con rebase y merge.
Git merge confirma la última confirmación que tuvimos en la rama de características y aquí el caso es con la confirmación f2, que reúne todos los cambios y la combina con la última confirmación que tenemos en la rama maestra, m3 aquí. Esto parece complicado pero se puede realizar fácilmente mediante el comando de combinación. Podemos hacer una combinación directa o una combinación de squash y la diferencia en ambas.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
El comando anterior tomará todas las confirmaciones de la función y también agregará el registro del maestro. Para evitar eso, podemos usar squash para que en el registro del maestro, después de m3, solo se confirme una y eso es de actualización
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
uno debe tener cuidado al usar git rebase e intentar evitarlo. La regla de oro es evitarlo utilizando ramas públicas.
Solo mira el escenario anterior. Esto puede suceder cuando intentas reajustar master en la parte superior de tu rama de características y nuestra rama master es pública, ahora la rama master está actualizada pero todos los demás están trabajando en una versión anterior de master. Dado que el rebase dará como resultado nuevos compromisos, git puede pensar que la historia de la rama maestra se ha separado de todos los demás. La única forma de resolver esto será sincronizar ambos maestros fusionándolos nuevamente y tener un conjunto resultante de confirmaciones que serán confusas.
Tabla comparativa de Git ReBase vs Merge
La siguiente tabla resume las comparaciones entre Git ReBase vs Merge:
| Base de comparación entre Rebase vs Merge | Rebase | Unir |
| Se compromete | Cambia y reescribe el historial creando una nueva confirmación para cada confirmación en la rama de origen. | Incorpora todos los cambios a la fuente pero mantiene la ascendencia de cada historial de confirmación incorpora todos los cambios a la fuente pero mantiene la ascendencia de cada historial de confirmación. |
| Selección | Aquí primero verificamos la rama que necesita ser modificada y luego seleccionamos el comando rebase para agregar actualizaciones a otros. | Aquí primero verifique la rama que debe fusionarse primero. Luego realice la operación de fusión y la última confirmación de la fuente se fusionará con la última confirmación del maestro. |
| Manejo de conflictos | Dado que la historia de compromiso se reescribirá para comprender el conflicto, será difícil en algunos casos. | El conflicto de fusión se puede manejar fácilmente entendiendo el error que se realizó durante la fusión. |
| regla de oro | Debería usarse en las ramas públicas ya que el historial de confirmación puede causar confusión. | No hay mucho daño al realizar ramas públicas. |
| Alcance | Los commits que alguna vez fueron accesibles ya no serán accesibles después de rebase ya que el historial de commits ha cambiado. | Los compromisos seguirán siendo accesibles de las ramas de origen. |
Conclusión
Merge y Rebase son un par de dos poderosas herramientas de Git y ambas se utilizan para incorporar los cambios en las ramas, pero debemos ser un poco cuidadosos con la rebase ya que reescribirá el historial de commits y usarlos en ramas públicas puede dificultar el trabajo. de otros causándoles confusión. Mientras que puede usar la opción de fusión ya que se puede acceder a sus confirmaciones desde la rama de origen y puede resolver fácilmente los conflictos de fusión si tenemos el conocimiento adecuado.
Artículos recomendados
Esta es una guía de la principal diferencia entre Git ReBase vs Merge. Aquí también discutimos las diferencias clave de Git ReBase vs Merge con infografías y tabla de comparación. También puede echar un vistazo a los siguientes artículos para obtener más información:
- Git Fetch vs Git Pull - Diferencias principales
- Abstracción vs Encapsulación | Comparación de los 6 principales
- Arquitectura HBase con ventajas
- Preguntas de la entrevista GIT | Top 11
- Sistema de control de versiones GIT
- Git Push
- Encapsulación en JavaScript
- Guía completa de comando remoto Git
- Tres etapas del ciclo de vida de Git con el flujo de trabajo
- ¿Cómo usar GIT Cherry-pick con Ejemplo?