Cómo comprobar si un repositorio remoto de Git tiene nuevos commits

Introducción

En este laboratorio, aprenderás cómo verificar si un repositorio remoto de Git tiene nuevos commits que aún no están presentes en tu repositorio local. Esta es una habilidad crucial para el desarrollo colaborativo, ya que te permite mantenerse actualizado con los cambios realizados por otros.

Comenzaremos simulando un repositorio remoto y agregándolo a nuestro proyecto local. Luego, utilizaremos el comando git fetch para recuperar información sobre las ramas y los commits del remoto sin fusionarlos. Finalmente, exploraremos cómo comparar tu rama local con su contraparte remota para identificar cualquier nuevo commit en el remoto.

Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL git(("Git")) -.-> git/BranchManagementGroup(["Branch Management"]) git(("Git")) -.-> git/CollaborationandSharingGroup(["Collaboration and Sharing"]) git(("Git")) -.-> git/DataManagementGroup(["Data Management"]) git/DataManagementGroup -.-> git/reset("Undo Changes") git/BranchManagementGroup -.-> git/log("Show Commits") git/CollaborationandSharingGroup -.-> git/fetch("Download Updates") git/CollaborationandSharingGroup -.-> git/pull("Update & Merge") git/CollaborationandSharingGroup -.-> git/remote("Manage Remotes") subgraph Lab Skills git/reset -.-> lab-560074{{"Cómo comprobar si un repositorio remoto de Git tiene nuevos commits"}} git/log -.-> lab-560074{{"Cómo comprobar si un repositorio remoto de Git tiene nuevos commits"}} git/fetch -.-> lab-560074{{"Cómo comprobar si un repositorio remoto de Git tiene nuevos commits"}} git/pull -.-> lab-560074{{"Cómo comprobar si un repositorio remoto de Git tiene nuevos commits"}} git/remote -.-> lab-560074{{"Cómo comprobar si un repositorio remoto de Git tiene nuevos commits"}} end

Obtener cambios remotos con git fetch

En este paso, aprenderemos cómo obtener cambios de un repositorio remoto. Imagina que estás trabajando en un proyecto con otros y ellos han realizado algunas actualizaciones. Necesitas traer esas actualizaciones a tu máquina local. El comando git fetch es la forma de hacerlo. Descarga los últimos cambios de un repositorio remoto, pero no los fusiona en tu rama actual.

Primero, simulemos tener un repositorio remoto. Crearemos un repositorio desnudo (bare repository) y luego lo agregaremos como remoto a nuestro repositorio my-time-machine existente.

cd ~/project
mkdir remote-repo.git
cd remote-repo.git
git init --bare

Esto crea un repositorio Git desnudo, que se utiliza típicamente como un repositorio central del que los desarrolladores realizan operaciones de push y pull.

Ahora, volvamos a nuestro repositorio my-time-machine y agreguemos este repositorio desnudo como remoto.

cd ~/project/my-time-machine
git remote add origin ~/project/remote-repo.git

Hemos nombrado nuestro remoto origin, que es una convención común. Ahora, verifiquemos que el remoto se haya agregado correctamente.

git remote -v

Deberías ver una salida similar a esta, que muestra las URLs de fetch y push para el remoto origin:

origin	/home/labex/project/remote-repo.git (fetch)
origin	/home/labex/project/remote-repo.git (push)

Ahora, simulemos un cambio en el repositorio remoto. Dado que es un repositorio desnudo, no podemos realizar commits directamente en él. En lugar de eso, simularemos un cambio creando un nuevo archivo en el directorio del repositorio desnudo.

cd ~/project/remote-repo.git
echo "This is a remote change" > remote_file.txt

Ahora, regresa a tu repositorio my-time-machine.

cd ~/project/my-time-machine

En este punto, tu repositorio local no sabe nada del archivo remote_file.txt que se agregó al repositorio remoto simulado. Aquí es donde entra en juego git fetch.

Ejecuta el comando git fetch:

git fetch origin

Puede que no veas mucha salida, o puede que veas algo que indique que se recibieron nuevos objetos.

Lo que hizo git fetch origin fue conectarse al remoto origin y descargar cualquier nuevo commit y objeto que no esté en tu repositorio local. Sin embargo, no fusionó estos cambios en tu rama actual (master). Los cambios ahora están disponibles en tu repositorio local, pero se almacenan en una rama especial que sigue al remoto, típicamente llamada origin/master.

Esta es una diferencia clave entre git fetch y git pull. git pull es esencialmente git fetch seguido de una fusión. Al usar primero git fetch, puedes ver qué cambios están disponibles en el remoto antes de decidir integrarlos en tu trabajo. Esto te da más control y ayuda a prevenir conflictos inesperados.

En el siguiente paso, veremos cómo comparar tu rama local con la rama remota obtenida para entender qué cambios se descargaron.

Ejecutar git log HEAD..@{u}

En el paso anterior, usamos git fetch para descargar cambios del repositorio remoto. Ahora, veamos cómo podemos ver los commits que están en el remoto pero aún no están en nuestra rama local. Aquí es donde el comando git log HEAD..@{u} es muy útil.

Asegúrate de que todavía estés en el directorio ~/project/my-time-machine.

cd ~/project/my-time-machine

Ahora, ejecuta el siguiente comando:

git log HEAD..@{u}

Puedes ver una salida similar a esta:

commit abcdef1234567890abcdef1234567890abcdef (origin/master)
Author: Simulated User <[email protected]>
Date:   Mon Aug 7 10:05:00 2023 +0000

    Simulated remote commit

Desglosemos este comando:

git log: Este es el comando para ver el historial de commits.
HEAD: Esto se refiere al commit al que apunta tu rama actual.
@{u}: Esta es una forma abreviada de la rama upstream (rama remota de seguimiento). En nuestro caso, dado que realizamos un fetch desde origin y nuestra rama local master está siguiendo a origin/master, @{u} se refiere a origin/master.
HEAD..@{u}: Esta es una notación de rango en Git. Significa "muéstrame los commits que son alcanzables desde @{u} pero no desde HEAD". En términos más simples, muestra los commits que están en la rama de seguimiento remota (origin/master) pero no están en tu rama local actual (master).

Este comando es increíblemente útil para ver qué cambios obtendrás si fueras a fusionar o rebasar tu rama local con la rama de seguimiento remota. Te permite revisar los cambios entrantes antes de integrarlos, lo cual es una parte crucial de un flujo de trabajo seguro y controlado.

Puedes preguntarte: "¿Cómo supo Git sobre el commit remoto simulado?" Cuando ejecutamos git fetch origin en el paso anterior, Git descargó la información sobre los commits en el repositorio origin, incluyendo el commit que introdujo remote_file.txt. Esta información se almacena en la rama de seguimiento origin/master en tu repositorio local. El comando git log HEAD..@{u} luego compara tu rama local master (HEAD) con esta rama de seguimiento origin/master (@{u}) para mostrarte la diferencia.

Presiona q para salir de la vista del log si está en modo de pantalla completa.

Comprender la diferencia entre tu rama local y la rama de seguimiento remota es fundamental para trabajar de manera efectiva con repositorios remotos. Este comando proporciona una forma clara de visualizar esas diferencias.

Probar remotos sincronizados

En los pasos anteriores, obtuvimos cambios de un repositorio remoto simulado y aprendimos cómo ver los commits que están en el remoto pero no en nuestra rama local utilizando git log HEAD..@{u}. Ahora, veamos qué sucede cuando nuestra rama local está actualizada con la rama de seguimiento remota.

Primero, simulemos la fusión de los cambios remotos en nuestra rama local. Mientras que git fetch solo descarga cambios, git pull descarga y luego fusiona. Con el propósito de esta prueba, simularemos el estado después de un pull actualizando manualmente nuestra rama local para que coincida con la rama de seguimiento remota.

Asegúrate de que estés en el directorio ~/project/my-time-machine.

cd ~/project/my-time-machine

Ahora, simulemos la fusión restableciendo nuestra rama local master al mismo commit que origin/master. Nota: En un escenario real, normalmente usarías git merge origin/master o git pull origin master para integrar cambios. Estamos usando git reset --hard aquí puramente con fines demostrativos para poner rápidamente nuestra rama local en sincronía con la rama de seguimiento remota para la prueba.

git reset --hard origin/master

Deberías ver una salida que indique que tu rama ha sido actualizada y que el árbol de trabajo está limpio.

HEAD is now at abcdef1 Simulated remote commit

Ahora que nuestra rama local master está sincronizada con origin/master, ejecutemos de nuevo el comando git log HEAD..@{u}.

git log HEAD..@{u}

Esta vez, no deberías ver ninguna salida.

¿Por qué no hay salida? Porque HEAD (nuestra rama local master) y @{u} (la rama de seguimiento origin/master) ahora apuntan al mismo commit. El rango HEAD..@{u} está vacío porque no hay commits alcanzables desde @{u} que no también sean alcanzables desde HEAD.

Este es el comportamiento esperado cuando tu rama local está completamente sincronizada con su rama de seguimiento remota upstream. El comando git log HEAD..@{u} es una forma rápida de comprobar si hay algún cambio entrante del remoto que aún no hayas integrado. Si el comando no muestra salida, significa que tu rama local está actualizada con la rama de seguimiento remota.

Comprender cómo comprobar los cambios entrantes y cómo interpretar la salida de git log HEAD..@{u} es esencial para colaborar con otros y mantener tu repositorio local sincronizado con el remoto.

Resumen

En este laboratorio (lab), aprendimos cómo comprobar si un repositorio remoto de Git tiene nuevos commits. Comenzamos entendiendo el propósito de git fetch, que descarga cambios de un repositorio remoto sin fusionarlos. Simulamos un repositorio remoto creando un repositorio Git bare (sin directorio de trabajo) y lo agregamos como un remoto llamado origin a nuestro repositorio local my-time-machine. Verificamos la configuración del remoto utilizando git remote -v.

A continuación, simulamos un cambio en el repositorio remoto creando un archivo directamente en el directorio del repositorio bare. Luego utilizamos el comando git fetch origin para recuperar estos cambios en nuestro repositorio local, preparándonos para comprobar si hay nuevos commits.