La mayoría de las integraciones de código ocurren con una fusión, pero ocasionalmente un desarrollador quiere que su código local se ponga al día con la rama maestra a través de un rebase en su lugar. En este ejemplo vamos a demostrar cómo git rebase una rama a master en lugar de usar el comando merge, mientras que también señalaremos el impacto de realizar una operación de git rebase a master.
¿Qué Git rebase al maestro decir?,
en este tutorial, tomaremos la rama llamada develop y la rebase en la punta de master.
la rama develop se separó de master en la confirmación C, Por lo que ambas ramas comparten los archivos a.html, b.html y c.html. Vea la imagen de abajo para ayudar a visualizar esto.
desde que se produjo la rama, master ha añadido confirmaciones D y E. Esto significa que master tiene dos archivos que develop no tiene, a saber d.html y e.html.,
así es como se ve el repositorio Git antes de una rebase de git a master.
Además, desde la división, ha habido dos nuevas confirmaciones en la rama develop, añadiendo los archivos f.html y g.html. Estos son archivos que la rama develop tiene que la rama master no tiene.
así es como el repositorio GitLab se ve después de la rebase de git a master.,
impacto de la rebase de Git
después de una rama de desarrollo exitosa a la rebase maestra:
- Los archivos de la rama maestra no cambiarán
- La rama de desarrollo además adquirirá todos los nuevos archivos de la rama maestra
- El punto de rama de la secuencia de desarrollo cambiará.
- aparecerá como si la rama develop se dividiera después de confirmar E en la rama master.
- Antes de la rebase, la rama develop se divide de master en la confirmación C.,
sintaxis de comando Git rebase to master
la operación para realizar un git rebase to master es sencilla. Simplemente agregue al final del comando el nombre de la rama de origen y luego el nombre de la rama a rebase. Para rebase develop to master el comando es el siguiente:
git rebase master develop
advertencia: hay un git rebase onto switch que a veces los desarrolladores creen incorrectamente que necesitan incluir con el comando rebase. Al hacerlo, las confirmaciones se descartarán y los archivos se perderán., No cometas el error de realizar una rebase de git sobre la operación.
antes de la rebase, la rama develop tenía solo cinco archivos.
Cada rama tiene cinco archivos antes de que el git rebase a la operación principal.
después de la rebase de Git a master, la rama develop tiene siete archivos. Ha conservado todos sus archivos originales y ha adquirido dos nuevos archivos de la punta de la rama principal., Sin embargo, el número de archivos en la rama maestra permanece sin cambios.
Después de que el git rebase de desarrollar a la maestra, a desarrollar la rama adquiere todos los de la maestra de archivos.
el hecho de que la rama master no haya adquirido ningún archivo de la rama develop a menudo desecha a los nuevos usuarios de Git, pero este es el comportamiento esperado. Una rebase de git no se sincroniza entre ramas. Simplemente captura una rama con los últimos cambios de otra.,
El número de archivos en desarrollar aumentar después de que el git rebase a la maestra.
proceda con precaución
Cuando se produce una rebase de Git, el historial de confirmaciones del repositorio se cambia irreparablemente. Después del cambio de base en nuestro ejemplo, las confirmaciones F Y G se asignan nuevos identificadores de confirmación, y los antiguos identificadores de confirmación se descartan. Por esta razón, a menudo verá confirmaciones rebasadas marcadas como F’ Y G’ para enfatizar el hecho de que se han asignado nuevos identificadores de confirmación.,
si rebase una rama compartida con otro desarrollador y devuelve sus cambios a GitHub o GitLab, un desarrollador compañero se encontrará con una variedad o problemas cuando intente extraer el repositorio rebasado a su entorno de desarrollo local. Las confirmaciones que tengan localmente habrán desaparecido en el remoto, y la rama remota tendrá un historial de rama incompatible. Como puedes imaginar, rebasar una rama compartida o aplastar las confirmaciones de Git puede causar estragos.,
Rebase a GitHub o GitLab
de hecho, si rebase e intenta enviar a GitLab o GitHub, el servidor no permitirá que se realice la operación. Para cambiar la base a GitHub o GitLab, un desarrollador debe agregar el interruptor-force al comando git push para obligar a que los cambios sean aceptados.
git push origin --force
Un GitLab o GitHub reajuste de empuje será rechazada, a menos forzada.,
la lógica aceptada es que solo git rebase para dominar las ramas locales de tu espacio de trabajo personal. De esa manera tus comandos de Git clean up no impactan a nadie más. No realice una rebase de git para dominar en ramas compartidas con otros desarrolladores. Un rebase en master está bien, pero no al revés. De lo contrario, es probable que rompa la compilación y las operaciones push o pull se pondrán en espera, frustrando el desarrollo continuo y convirtiéndolo en persona non grata con el resto de los desarrolladores y el equipo de DevOps.