Git rebase: Todo lo que necesitas saber
Publicado: 2022-12-15
El comando Git rebase combina dos ramas del código fuente en una sola. El comando merge de Git también hace eso. Explicamos qué hace rebase , cómo se usa y cuándo usar merge en su lugar.
La explosión de Git
¿Qué es la fusión de Git?
¿Qué es Git rebase?
Cómo cambiar de base a otra sucursal
Git Rebase vs. Merge: ¿Cuál debería usar?
¿Rebase o no Rebase?
La explosión de Git
Frustrado con otros sistemas de control de versiones y sus lentas actualizaciones y confirmaciones, Linus Torvalds, famoso por el kernel de Linux, dedicó un mes en 2005 a escribir el suyo propio. Lo llamó Git.
Sitios como GitHub, GitLab y BitBucket han promovido simbióticamente y se han beneficiado de Git. Hoy en día, Git se usa a nivel mundial, con un masivo 98 por ciento de 71 mil encuestados en una encuesta de 2022 que usa Git como sistema de control de versiones.
Una de las principales decisiones de diseño de Git fue la velocidad. En particular, el trabajo con ramas tenía que ser lo más rápido posible. Las sucursales son una parte fundamental de los sistemas de control de versiones. Un repositorio de proyectos tendrá una rama principal o maestra. Aquí es donde se encuentra el código base del proyecto. El desarrollo, como las nuevas funciones, se lleva a cabo en ramas laterales segregadas. Esto evita que el trabajo realizado en las ramas estropee la rama maestra y permite que se produzca un desarrollo simultáneo en diferentes partes de la base de código.
A medida que se completan los desarrollos en las ramas secundarias, los cambios se transfieren a la rama maestra al fusionar la rama de desarrollo con la rama maestra. En otros sistemas de control de versiones, trabajar con sucursales era difícil y computacionalmente costoso. Trabajar con ramas en Git es muy rápido y muy ligero. Lo que antes era un ejercicio tedioso y evitado en otros sistemas, se volvió trivial en Git.
El comando Git rebase es otra forma de transferir los cambios de una rama a otra rama. Los comandos merge y rebase tienen objetivos similares, pero logran sus fines de diferentes maneras y producen resultados ligeramente diferentes.
¿Qué es la fusión de Git?
Entonces, ¿para qué sirve el comando merge de Git? Supongamos que ha creado una rama llamada dev-branch para trabajar en una nueva característica.
Realiza algunas confirmaciones y prueba su nueva función. Todo funciona bien. Ahora desea enviar su nueva característica a la rama master . Debe estar en la rama master para fusionar otra con ella.
Podemos asegurarnos de que estamos en la rama master revisándola explícitamente antes de fusionarnos.
maestro de pago de git
Ahora podemos decirle a Git que fusione la dev-branch con la rama actual, que es la rama master .
rama de desarrollo de git merge
Nuestra merge está completa para nosotros. Si revisa la rama master y la compila, tendrá la característica recientemente desarrollada. Lo que Git realmente ha realizado es una combinación de tres vías. compara las confirmaciones más recientes en las ramas master y dev-branch desarrollo, y la confirmación en la rama master inmediatamente antes de que se creara dev-branch desarrollo. Luego realiza una confirmación en la rama master .
Las fusiones se consideran no destructivas porque no eliminan nada y no cambian nada del historial de Git. La dev-branch todavía existe y ninguna de las confirmaciones anteriores se modifica. Se crea una nueva confirmación que captura los resultados de la combinación de tres vías.
Después de la fusión, nuestro repositorio de Git parece una línea de tiempo con una línea alternativa que se bifurca y luego regresa a la línea de tiempo principal.
La dev-branch se ha incorporado a la rama master .
Si tiene muchas sucursales en un proyecto, la historia del proyecto puede volverse confusa. Este suele ser el caso si un proyecto tiene muchos colaboradores. Debido a que el esfuerzo de desarrollo se divide en muchas rutas diferentes, el historial de desarrollo no es lineal. Desenredar el historial de confirmaciones se vuelve aún más difícil si las sucursales tienen sus propias sucursales.
Tenga en cuenta que si tiene cambios no confirmados en la rama master , deberá hacer algo con estos cambios antes de poder fusionarlos. Puede crear una nueva rama y confirmar los cambios allí, y luego realizar la fusión. Luego, deberá fusionar su rama temporal nuevamente en la rama principal.
Eso funciona, pero Git tiene un comando que logra lo mismo, sin tener que crear nuevas ramas. El comando stash almacena los cambios no confirmados por usted y le permite recuperarlos con stash pop .
Los usarías así:
reserva rama de desarrollo de git merge alijo pop
El resultado final es una rama fusionada, con los cambios no guardados restaurados.
¿Qué es Git rebase?
El comando Git rebase logra sus objetivos de una manera completamente diferente. Toma todas las confirmaciones de la rama en la que se va a reorganizar y las reproduce en el final de la rama en la que se está reorganizando.
Tomando nuestro ejemplo anterior, antes de realizar cualquier acción, nuestro repositorio de Git se ve así. Tenemos una rama llamada dev-branch y queremos mover esos cambios a la rama master .
Después de la rebase , parece una única línea de tiempo de cambios completamente lineal.
Se eliminó dev-branch desarrollo y las confirmaciones en la dev-branch desarrollo se agregaron a la rama maestra. El resultado final es el mismo que si las confirmaciones en la dev-branch desarrollo se hubieran confirmado directamente en la rama master en primer lugar. Las confirmaciones no solo se agregan a la rama master , sino que se "reproducen" y se agregan nuevas.
Esta es la razón por la que el comando rebase se considera destructivo. La rama reorganizada ya no existe como una rama separada y el historial de Git de su proyecto se ha reescrito. No puede determinar en algún momento posterior qué confirmaciones se realizaron originalmente en dev-branch .
Sin embargo, te deja con una historia simplificada y lineal. En comparación con un repositorio con docenas o incluso cientos de ramificaciones y fusiones, leer el registro de Git o usar una GUI gráfica de Git para ver un gráfico del repositorio, un repositorio reorganizado es muy fácil de entender.
Cómo cambiar de base a otra rama
Probemos un ejemplo de git rebase . Tenemos un proyecto con una rama llamada new-feature . Volveríamos a rebase esa rama en la rama master de esta manera.
Primero, verificamos que la rama master no tenga cambios pendientes.
estado de Git
Echamos un vistazo a la rama new-feature .
nueva característica de git checkout
Le decimos a Git que vuelva a rebase la rama actual en la rama maestra.
maestro de rebase de git
Podemos ver que todavía tenemos dos sucursales.
rama git
Cambiamos de nuevo a la rama master
maestro de pago de git
Fusionamos la rama de características nuevas con la rama actual, que en nuestro caso es la rama master .
nueva característica de git merge
Curiosamente, todavía tenemos dos sucursales después de la fusión final.
La diferencia es que ahora el jefe de la rama de new-feature y el jefe de la rama master están configurados para apuntar a la misma confirmación, y el historial de Git no muestra que solía haber una rama new-feature separada, aparte de la etiqueta de la rama.
Git Rebase vs. Merge: ¿Cuál debería usar?
No es un caso de rebase vs. merge . Ambos son comandos poderosos y probablemente los usará a ambos. Dicho esto, hay casos de uso en los que rebase no funciona tan bien. Deshacer errores causados por errores al usar merge es desagradable, pero eliminar errores causados por rebase es infernal.
Si es el único desarrollador que usa un repositorio, hay menos posibilidades de que haga algo desastroso con la rebase . Todavía podría rebase la base en la dirección incorrecta, por ejemplo, y rebase la base de su rama maestra en su rama de new-feature . Para recuperar su rama master , necesitaría volver a establecer la rebase , esta vez desde su rama de new-feature a su rama master . Eso restauraría su rama master , aunque con un historial de aspecto extraño.
No use rebase en sucursales compartidas donde es probable que otros trabajen. Tus cambios en tu repositorio van a causar problemas a muchas personas cuando envíes tu código rebasado a tu repositorio remoto.
Si su proyecto tiene varios colaboradores, lo más seguro es usar rebase solo en su repositorio local , y no en sucursales públicas. Del mismo modo, si las solicitudes de extracción forman parte de sus revisiones de código, no use rebase . O al menos, no use rebase después de crear la solicitud de extracción. Es probable que otros desarrolladores observen sus confirmaciones, lo que significa que esos cambios están en una rama pública, incluso si no están en la rama master .
El peligro es que va a volver a rebase confirmaciones que ya se han enviado a un repositorio remoto, y es posible que otros desarrolladores ya hayan basado el trabajo en esas confirmaciones. Su rebase local hará que desaparezcan esos compromisos existentes. Si envía esos cambios al repositorio, no será popular.
Otros colaboradores tendrán que pasar por una merge desordenada para que su trabajo vuelva al repositorio. Si luego vuelve a colocar sus cambios en su repositorio local, se enfrentará a deshacer un lío de cambios duplicados.
¿Rebase o no Rebase?
Rebase podría estar prohibido en su proyecto. Puede haber objeciones culturales locales. Algunos proyectos u organizaciones consideran el rebase como una forma de herejía y un acto de profanación. Algunas personas creen que el historial de Git debería ser un registro permanente e inviolable de lo que sucedió. Entonces, rebase podría estar fuera de la mesa.
Pero, usado localmente, en sucursales privadas, rebase es una herramienta útil.
Empuje después de que haya reorganizado y restríjalo a las sucursales donde usted es el único desarrollador. O al menos, donde todo el desarrollo se ha detenido y nadie más ha basado ningún otro trabajo en las confirmaciones de su rama.
Haz eso y te evitarás cualquier problema.
RELACIONADO: Cómo verificar y actualizar su versión de Git