Reorganizar la rama local al extraer cambios de la rama del repositorio remoto en Git

Este tutorial presentará el cambio de base de la rama local al extraer cambios de la rama del repositorio remoto en Git.

Usamos Git, un sistema de control de versiones, para realizar un seguimiento de los cambios realizados en los archivos. Confirmamos los cambios en la rama local del repositorio local. Esta rama local está asociada con una rama remota del repositorio remoto.

De vez en cuando, sincronizamos los cambios del repositorio remoto con los presentes en nuestro repositorio local. Extraemos los cambios de la rama remota a la rama local.

Cuando extraemos los cambios de la rama remota, podemos reorganizar la rama local (es decir,) para volver a aplicar los cambios no publicados además de los cambios publicados.

Ahora ilustraremos esto con un ejemplo.

Uso de git pull --rebase para cambiar la base de la rama local al extraer de la rama del repositorio remoto en Git

En un entorno de desarrollo colaborativo, creamos ramas en el repositorio local en nuestro sistema local utilizando Git. Asociamos esta rama local con una rama remota en el repositorio remoto.

Preparamos y confirmamos los cambios realizados en los archivos en nuestra rama local. Luego publicamos estos cambios en la rama remota en el repositorio remoto.

Luego, otros miembros del equipo, que también están trabajando con el mismo repositorio, extraen los cambios publicados en las ramas locales de sus sistemas.

Por lo tanto, periódicamente, realizamos este proceso de enviar cambios locales al repositorio remoto y extraer los cambios publicados del repositorio remoto.

Al incorporar los cambios publicados de la rama remota en nuestra rama local, tenemos la opción de fusionar o reorganizar.

En caso de fusión, usamos el comando git pull --merge, la opción predeterminada. Cuando extraemos los cambios del repositorio remoto en el caso de fusión, los cambios locales se fusionan con los cambios remotos.

Se crea un commit de combinación para apuntar a las últimas commits locales y remotas.

En caso de rebase, usamos el comando git pull --rebase. En una reorganización, los cambios locales no publicados de la rama local se vuelven a aplicar sobre los cambios publicados del repositorio remoto.

No se crea un nuevo commit en el caso de rebase.

Supongamos que tenemos una rama llamada feature en el repositorio local asociada con una rama remota con el mismo nombre en el repositorio remoto.

Cada desarrollador en el equipo tendría la rama local feature en su sistema local.

Supongamos que un desarrollador ha realizado algunos cambios en la feature de la rama local.

Ahora, supongamos que otros desarrolladores han publicado algunos cambios en la feature de la rama remota del repositorio remoto.

Por lo tanto, ahora la situación de las ramas se ve como se muestra en la ilustración a continuación.

              P---Q---R feature (local branch)
             /
A---B---C---D---E---G feature (remote branch)

Como se muestra en la ilustración anterior, ahora tenemos un historial bifurcado. Necesitamos extraer los cambios de la rama remota a la rama local para obtener los cambios publicados.

Supongamos que los nuevos commits de la rama remota feature son relevantes para las de la rama local (que suele ser el caso). Por lo tanto, haríamos una reorganización en lugar de una fusión al realizar una extracción en este caso.

Necesitamos ejecutar el comando git pull con la opción --rebase para hacer un rebase. La sintaxis del comando es, git pull --rebase <remote-repository> <remote-branch-name>.

Así, en nuestro caso, para rebase nuestra rama local feature, haríamos lo siguiente.

$ git pull --rebase origin feature

Por lo tanto, después de ejecutar el comando git pull anterior, las ramas se ven como se muestra en la ilustración a continuación.

                      P---Q---R feature (local branch)
                     /
A---B---C---D---E---G feature (remote branch)

Por lo tanto, como se muestra en la ilustración, todas los commits no publicadas de la feature de la rama local se mueven en la punta de los cambios de feature de la rama remota. No se crea un nuevo commit.

La principal ventaja de la opción de reorganización es que el historial del proyecto es mucho más limpio que con la opción de fusión.

Además, como se muestra en la ilustración anterior, obtenemos un historial de proyecto lineal. No hay tenedores presentes. Uno navega fácilmente a través de la historia del proyecto usando el comando git log.

Por lo tanto, hemos explicado cómo cambiar la base de la rama local al extraer cambios del repositorio remoto en Git.

Para mayor información por favor visite -

1. git-pull
2. Fusionar vs. Rebasar