Clonando y haciendo pull

Ahora que tenemos el código en un remoto vamos a ver cómo podemos acceder a él de cero usando clone y cómo podemos recibir commits de un remoto usando pull.

Cuando trabajamos con Git, una de las primeras cosas que necesitamos es obtener una copia completa de un repositorio remoto para poder empezar a trabajar localmente. Para ello, utilizamos el comando git clone, que podemos ejecutar desde cualquier carpeta de nuestro sistema, sin necesidad de estar dentro de otro repositorio. Este comando nos permite descargar todo el repositorio, no solo los archivos visibles, sino también todo el historial de commits y objetos que forman parte del proyecto.

Al clonar un repositorio, Git crea una carpeta con el nombre del proyecto y dentro de ella tenemos todo el contenido, junto con el historial completo. Esto significa que, aunque el servidor remoto deje de estar disponible, nosotros seguimos teniendo una copia íntegra del repositorio en nuestra máquina. Por ejemplo, si clonamos un proyecto llamado Página Cliente, al entrar en esa carpeta podremos usar comandos como git log para ver todos los commits realizados desde el inicio, o git checkout para movernos entre diferentes versiones del código.

Además, cuando clonamos un repositorio, Git automáticamente configura un remoto llamado origin que apunta al repositorio del que hemos hecho la copia. Esto nos permite trabajar con normalidad y, si tenemos permisos, enviar cambios al repositorio remoto usando git push origin. Así, el flujo de trabajo queda listo para que podamos colaborar y mantener sincronizado nuestro código.

Ahora bien, si hemos descargado un repositorio para simplemente usarlo o para contribuir a un proyecto de código abierto, es importante saber cómo mantener nuestra copia local actualizada con los cambios que otros puedan hacer en el repositorio remoto. Para ello, utilizamos el comando git pull, que básicamente le pide a Git que revise si hay nuevos commits en el remoto y los descargue a nuestra copia local.

Cuando ejecutamos git pull origin master, por ejemplo, Git se conecta al remoto origin y descarga los cambios de la rama master. Esto actualiza nuestra copia local con las últimas modificaciones. Durante este proceso, Git puede pedirnos autenticación si el repositorio está protegido, y una vez completado, veremos que nuestro historial de commits se ha actualizado con los nuevos cambios.

Un detalle interesante es que, tras hacer un git pull, Git crea referencias especiales llamadas ramas remotas, que podemos ver con el comando git branch -a. Estas ramas remotas tienen nombres como remotes/origin/master o remotes/origin/HEAD. Estas referencias representan el estado de las ramas en el repositorio remoto y nos permiten comparar y trabajar con ellas. Por ejemplo, origin/HEAD suele apuntar a la rama principal del remoto, que normalmente es master, aunque esto puede configurarse para que sea otra rama.

En resumen, las ramas remotas son una forma que tiene Git de mantener sincronizado nuestro repositorio local con el remoto, y entender cómo funcionan nos ayuda a gestionar mejor nuestro flujo de trabajo. En próximos pasos, podemos explorar cómo hacer merges o trabajar con estas ramas remotas para integrar cambios de manera más avanzada.

Lista de reproducción
  1. 1
    ¿Qué es Git?
    4 minutos
  2. 2
    Cómo instalar Git
    9 minutos
  3. 3
    Creando tu primer commit
    9 minutos
  4. 4
    Qué es el staging area
    10 minutos
  5. 5
    Cómo deshacer modificaciones de archivos
    7 minutos
  6. 6
    Cómo deshacer un commit con reset
    7 minutos
  7. 7
    Cómo revertir un commit con revert
    7 minutos
  8. 8
    Introducción a las ramas
    6 minutos
  9. 9
    Cómo crear y modificar ramas
    6 minutos
  10. 10
    Commits bajo el workflow Feature Branch
    6 minutos
  11. 11
    Cómo fusionar ramas con merge
    6 minutos
  12. 12
    Fusiones conflictivas
    9 minutos
  13. 13
    Cómo construir alias
    7 minutos
  14. 14
    Más sobre conflictos
    9 minutos
  15. 15
    Etiquetas
    7 minutos
  16. 16
    Tags anotados
    9 minutos
  17. 17
    git stash: esconder cambios
    6 minutos
  18. 18
    Introducción a remotos
    5 minutos
  19. 19
    Pusheando a un remoto
    6 minutos
  20. 20
    Clonando y haciendo pull
    6 minutos
  21. 21
    Fetch y pull rebases
    8 minutos
  22. 22
    Rebase
    7 minutos
  23. 23
    Rebase interactivo
    6 minutos
  24. 24
    Master, main y otros nombres de rama
    9 minutos
  25. 25
    git switch
    9 minutos
  26. 26
    git-restore
    10 minutos
  27. 27
    git-grep
    11 minutos
  28. 28
    Gitignore
    11 minutos
  29. 29
    El flag --patch
    9 minutos
  30. 30
    git-apply y parches en bruto (advanced)
    9 minutos
  31. 31
    Merge octopus (advanced)
    9 minutos
  32. 32
    Conventional commits
    12 minutos
  33. 33
    Merge and squash (GitLab / GitHub...)
    6 minutos
  34. 34
    git merge --squash
    7 minutos
  35. 35
    git-bisect
    8 minutos
  36. 36
    git-blame
    6 minutos
  37. 37
    git-reflog
    10 minutos
  38. 38
    Git para la Bash
    11 minutos
  39. 39
    Submódulos (parte 1)
    7 minutos
  40. 40
    Submódulos (parte 2)
    10 minutos
  41. 41
    Otros clientes Git (último episodio)
    9 minutos