git clone: cómo clonar un repositorio de GitHub paso a paso

Entras a un equipo nuevo, alguien te pasa un enlace de GitHub y la primera instrucción del día es “clónate el repo”. Suena a copiar unos archivos, pero la cosa tiene más chicha: cuando clonas un repositorio con git clone no bajas solo el código de hoy, bajas el proyecto entero con toda su historia y una conexión al original ya montada. Aquí te explico qué te deja exactamente en el ordenador y por qué eso importa. Es una de las primeras piezas de trabajar en equipo con Git y GitHub: antes de colaborar, necesitas la copia del proyecto en tu ordenador.

Para seguir esto solo necesitas tener Git instalado en tu ordenador. Para clonar un repositorio público por HTTPS no hace falta nada más. La cuenta de GitHub entra en juego cuando uses SSH o quieras enviar tus cambios con git push, que es justo lo normal cuando entras en un equipo.

¿Qué hace git clone exactamente?

git clone copia un repositorio remoto entero a tu máquina: los archivos, todo el historial de cambios y una conexión ya configurada al repositorio original ^[1]. No es una descarga suelta de la última versión. Es una réplica funcional del proyecto lista para trabajar.

Vamos por partes, porque aquí hay dos palabras que quizá nadie te ha explicado todavía.

Un remoto es una copia del proyecto que vive en un servidor, en este caso en GitHub. Es la versión “oficial” que comparte todo el equipo. Cuando tú y tres compañeros trabajáis sobre el mismo proyecto, cada uno tiene su copia en local y todas apuntan al mismo remoto.

El historial son todos los commits del proyecto. Un commit es una foto guardada del código en un momento concreto, con un mensaje que dice qué cambió. Clonar te trae esas fotos desde el primer día, no solo la última. Por eso puedes ver quién tocó qué, cuándo y por qué, sin pedirle nada a nadie.

¿Cómo clono un repositorio paso a paso?

Copias la URL del repositorio desde GitHub y ejecutas git clone seguido de esa URL. Git crea una carpeta, mete el proyecto dentro y configura la conexión al remoto en un solo paso.

# Clona el repositorio en una carpeta nueva dentro del directorio actual
git clone https://github.com/usuario/proyecto.git

# Entra en la carpeta que Git acaba de crear
cd proyecto

¿De dónde sale el nombre proyecto? Git usa la última parte de la URL (sin el .git) para nombrar la carpeta. Si el repo se llama proyecto.git, la carpeta se llama proyecto. Si quieres otro nombre, lo pones al final del comando:

# Clona el mismo repo pero en una carpeta llamada mi-carpeta
git clone https://github.com/usuario/proyecto.git mi-carpeta

¿Cómo compruebas que el historial vino completo y no solo los archivos de hoy? Con git log:

# Muestra el historial de commits, uno por línea
git log --oneline

La salida es una lista de commits, del más reciente al más antiguo, cada uno con su identificador corto delante:

a1b3c9d Añade validación al formulario de registro
7f2e0a4 Corrige el cálculo del total en el carrito
3c8d1b2 Primer commit

Ese código raro del principio de cada línea (a1b3c9d) es el hash del commit, su huella única. Si ves varios commits ahí, incluido uno de hace meses, la prueba está hecha: tienes la historia entera, no una foto suelta.

Antes de seguir, pruébalo tú: en este ejercicio interactivo clonas un repositorio y ves qué te queda en local, sin salir de la página.

Cargando ejercicio...

¿HTTPS o SSH? ¿Cuál elijo?

Son dos maneras de conectarte al mismo repositorio, y se distinguen a simple vista por cómo empieza la URL. GitHub te ofrece las dos cuando pulsas el botón “Code” del repo ^[2].

# Opción HTTPS: la URL empieza por https://
git clone https://github.com/usuario/proyecto.git

# Opción SSH: la URL empieza por git@ y lleva dos puntos antes de la ruta
git clone git@github.com:usuario/proyecto.git

Fíjate en la diferencia de la URL SSH: después de github.com hay dos puntos (:), no una barra. Es un despiste clásico al copiarla a mano.

¿Y en qué cambia usar una u otra? En cómo demuestras que eres tú.

	HTTPS	SSH
Empieza por	https://	git@
Configuración previa	Ninguna, funciona al instante	Generar una clave SSH y añadirla a GitHub, una vez
Qué te pide	Usuario y un token de acceso personal	Nada, si la clave ya está

Si es tu primera vez y solo quieres bajar el repo hoy, tira de HTTPS: no configuras nada. Cuando empieces a clonar y a hacer push a diario, SSH te ahorra teclear credenciales todo el rato, porque configuras la clave una sola vez y te olvidas.

¿Qué es origin y por qué aparece solo?

origin es el nombre que Git le pone por defecto al remoto del que acabas de clonar ^[1]. Tú no lo escribes en ningún sitio: git clone lo crea solo. Es un apodo para no tener que repetir la URL larga cada vez que quieras traer o enviar cambios.

Lo ves con git remote -v, dentro de la carpeta del proyecto:

# Lista los remotos configurados y sus URLs
git remote -v

origin  https://github.com/usuario/proyecto.git (fetch)
origin  https://github.com/usuario/proyecto.git (push)

Aparecen dos líneas con el mismo nombre. (fetch) es la URL desde la que Git trae los cambios de los demás; (push) es la URL a la que Git envía los tuyos. Normalmente son la misma, así que verás la URL repetida. A partir de ahí, cuando escribas git pull o git push, Git sabe que “el remoto” es origin sin que se lo digas. Si quieres entender a fondo cómo funcionan los remotos y añadir uno tú mismo, tienes la guía de conectar tu repositorio a un remoto en GitHub.

git clone o git init: ¿en qué se diferencian?

git clone trae un proyecto que ya existe; git init arranca uno nuevo desde cero. Esa es toda la diferencia, y cambia por completo con qué te quedas.

Cuando ejecutas git init en una carpeta, Git la convierte en un repositorio vacío: sin historial y sin ningún remoto configurado ^[3].

# Crea un repositorio nuevo y vacío en la carpeta actual
git init

Después de eso, un git log no muestra nada (todavía no hay commits) y un git remote -v sale en blanco (no hay ningún GitHub al que apuntar). Empiezas de cero, tú pones el primer commit y tú conectas el remoto más tarde.

	git clone	git init
Para qué sirve	Traer un repositorio que ya existe	Empezar un proyecto nuevo
Historial previo	Sí, viene entero	No, arrancas vacío
Remoto origin	Configurado automáticamente	Ninguno, lo añades tú luego
Punto de partida	El proyecto tal cual está en GitHub	Una carpeta vacía
Cuándo usarlo	Te unes a algo que ya rueda	Creas algo desde la nada

Regla práctica: si alguien te pasa un enlace, clonas. Si el proyecto todavía no existe en ningún servidor y lo estás inventando tú, haces init. Y hay un tercer caso que confunde a mucha gente al principio, clonar un proyecto que no es tuyo para contribuir: eso mezcla clone con otra operación, y lo aclaramos en la diferencia entre hacer fork y clonar.

Errores frecuentes al clonar (y qué significan)

fatal: repository '...' not found

Este es el más común y casi siempre es una de dos cosas. O la URL tiene una errata (una letra de más, el nombre del usuario mal), o el repositorio es privado y tu cuenta no tiene acceso. Git no distingue entre “no existe” y “existe pero no es para ti”, por seguridad. Revisa la URL carácter a carácter y, si es correcta, pídele acceso a quien lo administre.

Permission denied (publickey)

Sale cuando clonas por SSH pero no tienes una clave SSH configurada en GitHub. Es la manera de Git de decir “no sé quién eres”. La solución rápida si tienes prisa: clona por HTTPS en su lugar. La solución buena: genera una clave SSH y añádela a tu cuenta de GitHub una vez.

Clonar dentro de otra carpeta que ya es un repositorio

Un fallo silencioso que despista un montón. Estás dentro de la carpeta de un proyecto que ya clonaste, se te olvida, y clonas otro repo ahí dentro. Ahora tienes un repositorio metido dentro de otro y Git empieza a comportarse raro. Antes de clonar, mira dónde estás con pwd y clona en un sitio limpio, como tu carpeta de proyectos.

Bajar el ZIP no es clonar

GitHub tiene un botón para descargar el proyecto como ZIP, y es tentador. Pero ese ZIP trae solo los archivos de la versión actual: nada de historial, nada de remoto. No podrás hacer git pull para traer cambios ni git push para enviarlos, porque esa carpeta ni siquiera es un repositorio de Git. Si vas a trabajar de verdad sobre el proyecto, clona.

Comprueba que has clonado bien

• Estás dentro de la carpeta del proyecto (usa cd después de clonar)
• git log --oneline muestra commits, no un mensaje de repositorio vacío
• git remote -v muestra origin con su URL en las líneas de fetch y push
• La URL de origin coincide con la del repositorio que querías clonar
• No has clonado dentro de otra carpeta que ya era un repositorio

Clonar es el primer gesto de trabajar con código de verdad, y a partir de ahí vienen ramas, commits, pull y push. Si quieres practicar todo el flujo con ejercicios guiados en lugar de leerlo suelto, el curso Git de cero a profesional te lleva paso a paso desde el primer git clone hasta colaborar en equipo sin miedo.

Fuentes

1. Documentación oficial de git clone (git-scm.com): comportamiento por defecto, nombra el remoto origin, crea ramas de seguimiento para cada rama remota y hace checkout solo de la rama por defecto.
2. Cloning a repository (GitHub Docs): formato de las URLs HTTPS y SSH y pasos para clonar desde la interfaz de GitHub.
3. Documentación oficial de git init (git-scm.com): git init crea un repositorio vacío, sin historial ni remoto configurado.

Preguntas Frecuentes

¿git clone me trae todas las ramas?

Sí. Al clonar, Git descarga todas las ramas del repositorio remoto y crea una rama de seguimiento para cada una ^[1]. Lo que pasa es que solo deja activa (con checkout) la rama por defecto, normalmente main. Las demás están ahí, listas para usar: las ves con git branch --remotes y cambias a cualquiera cuando la necesites.

¿Puedo cambiar de HTTPS a SSH después de clonar?

Sí, y no hace falta volver a clonar. Cambias la URL del remoto origin con un solo comando:

# Cambia la URL de origin de HTTPS a SSH
git remote set-url origin git@github.com:usuario/proyecto.git

Después compruébalo con git remote -v y verás la URL nueva en las líneas de fetch y push.

¿Necesito hacer git init después de clonar?

No. git clone ya inicializa el repositorio por dentro, así que la carpeta clonada es un repositorio de Git en toda regla desde el primer segundo. Hacer git init encima no rompe nada, pero es innecesario. Solo usas init cuando empiezas un proyecto desde cero.

¿Dónde se guarda el repositorio clonado?

En una carpeta nueva dentro del directorio en el que estabas cuando ejecutaste el comando. Si estabas en ~/proyectos y clonaste proyecto.git, tu repo queda en ~/proyectos/proyecto. Por eso conviene situarte antes en tu carpeta de proyectos y comprobar con pwd que no estás dentro de otro repositorio.

Un concepto nuevo cada semana

Suscribirme