El comando Git rebase mueve una rama a una nueva ubicación en la cabecera de otra rama. A diferencia del comando de fusión de Git, rebase implica volver a escribir el historial de su proyecto. Es una gran herramienta, pero no rebase las confirmaciones en las que otros desarrolladores han basado el trabajo.
el git rebase El comando combina dos ramas del código fuente en una sola. el git merge comando hace eso también. Te explicamos qué rebase hace, cómo se usa y cuándo usar merge en cambio.
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 características, se lleva a cabo en ramas laterales segregadas. Esto evita que el trabajo realizado en las ramas estropee la rama principal 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 laterales, 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 git rebase El comando es otra forma de transferir los cambios de una rama a otra rama. los merge y rebase Los comandos tienen objetivos similares, pero logran sus fines de diferentes maneras y producen resultados ligeramente diferentes.
¿Qué es la fusión de Git?
Entonces, ¿qué es el Git? merge comando para? Digamos que ha creado una rama llamada dev-branch para trabajar en una nueva función.
Realiza algunas confirmaciones y prueba su nueva función. Todo funciona bien. Ahora desea enviar su nueva función al master rama. debes estar en el master rama para unir otra a ella.
Podemos asegurarnos de que estamos en el master ramificación revisándola explícitamente antes de fusionarnos.
git checkout master
Ahora podemos decirle a Git que fusione el dev-branch en la rama actual, que es la master rama.
git merge dev-branch
Nuestro merge se completa para nosotros. Si revisas el master ramificar y compilarlo, tendrá la característica recientemente desarrollada. Lo que Git realmente ha realizado es una combinación de tres vías. compara los commits más recientes en el master y dev-branch sucursales, y la confirmación en el master sucursal inmediatamente antes de la dev-branch fue creado. A continuación, realiza una confirmación en el master rama.
Las fusiones se consideran no destructivas porque no eliminan nada y no cambian nada del historial de Git. los 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.
los dev-branch sucursal se ha incorporado a la master rama.
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 el master branch, deberá hacer algo con estos cambios antes de poder fusionar algo en él. 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. los stash El comando almacena los cambios no confirmados por usted y le permite recuperarlos con stash pop .
Los usarías así:
stash git merge dev-branch stash pop
El resultado final es una rama fusionada, con los cambios no guardados restaurados.
¿Qué es Git rebase?
el git rebase comando 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 sucursal llamada dev-branch y queremos mover esos cambios a la master rama.
Después de la rebase parece una única línea de tiempo de cambios completamente lineal.
los dev-branch ha sido eliminado, y las confirmaciones en el dev-branch se han agregado a la rama principal. El resultado final es el mismo que si las confirmaciones en el dev-branch en realidad se había comprometido directamente con el master rama en primer lugar. Las confirmaciones no solo se añaden al master rama, se «reproducen» y se agregan nuevos.
Esta es la razón por la cual el rebase comando 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 el dev-branch.
Sin embargo, te deja con una historia simplificada y lineal. En comparación con un repositorio con docenas o incluso cientos de ramas 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 git rebase ejemplo. Tenemos un proyecto con una rama llamada new-feature. Casarse rebase esa rama hacia el master rama como esta.
Primero, comprobamos que el master sucursal no tiene cambios destacados.
git status
Verificamos el new-feature rama.
git checkout new-feature
Le decimos a Git que rebase la rama actual en la rama maestra.
git rebase master
Podemos ver que todavía tenemos dos sucursales.
git branch
Cambiamos de nuevo a la master rama
git checkout master
Fusionamos la rama de nuevas funciones con la rama actual, que en nuestro caso es la master rama.
git merge new-feature
Curiosamente, todavía tenemos dos sucursales después de la fusión final.
La diferencia es que ahora el jefe de la new-feature rama y el jefe de la master rama están configurados para apuntar a la misma confirmación, y el historial de Git no muestra que solía haber una new-feature rama, aparte de la etiqueta de la rama.
Git Rebase vs. Merge: ¿Cuál debería usar?
no es un caso de rebase contra merge. Ambos son comandos poderosos y probablemente los usará a ambos. Dicho esto, hay casos de uso en los que rebase realmente no funciona tan bien. Desechar errores causados por errores usando merge son desagradables, pero los errores de eliminación causados por rebase es infernal
Si es el único desarrollador que usa un repositorio, hay menos posibilidades de que haga algo con rebase eso es desastroso. todavía podrías rebase en la dirección equivocada, por ejemplo, y rebase su rama principal en su new-feature rama. para conseguir tu master bifurcarse hacia atrás, necesitaría rebase otra vez, esta vez de su new-feature ramifica a tu master rama. Eso restauraría su master rama, aunque con una historia de aspecto extraño.
no usar 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 solo rebase en tu local repositorio, 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 usar rebase después de crear la solicitud de extracción. Es probable que otros desarrolladores estén mirando sus confirmaciones, lo que significa que esos cambios están en una rama pública, incluso si no están en el master rama.
El peligro es que vas a rebase confirmaciones que ya se han enviado a un repositorio remoto, y es posible que otros desarrolladores ya hayan basado su trabajo en esas confirmaciones. tu local rebase hará que esos compromisos existentes desaparezcan. Si envía esos cambios al repositorio, no será popular.
Otros colaboradores tendrán que pasar por un complicado merge para que su trabajo sea devuelto 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 fuera de la ley en su proyecto. Puede haber objeciones culturales locales. Algunos proyectos u organizaciones consideran 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ó. Asi que, rebase podría estar fuera de la mesa.
Pero, usado localmente, en sucursales privadas, rebase es una herramienta útil.
Empujar después ha reorganizado y restringirlo a 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