git clone: cómo clonar un repositorio de GitHub y de otros servidores

El comando git clone crea una copia local completa de un repositorio remoto: archivos, todo el historial de commits, ramas y etiquetas. Es la forma estándar de empezar a trabajar en un proyecto que ya está en GitHub, GitLab o en un servidor de la empresa. A diferencia de descargar un ZIP, un clon es un repositorio de verdad en el que puedes hacer commits y enviar cambios de vuelta.

Uso básico de git clone

Copia la dirección del repositorio (en GitHub, el botón verde «Code») y ejecuta:

git clone https://github.com/username/project.git

Cloning into 'project'...
remote: Enumerating objects: 1532, done.
remote: Counting objects: 100% (1532/1532), done.
remote: Compressing objects: 100% (812/812), done.
Receiving objects: 100% (1532/1532), 2.41 MiB | 6.10 MiB/s, done.
Resolving deltas: 100% (701/701), done.

Git creará la carpeta project en el directorio actual (el nombre sale de la dirección sin .git). Después entra en ella:

cd project
git status

Qué hace git clone por dentro

Clonar no es solo descargar archivos. Entender estos pasos explica por qué después del clon todo «funciona sin más» y de dónde salen las ramas con el prefijo origin/. Paso a paso, el comando:

1. crea la carpeta y ejecuta en ella el equivalente a git init;
2. añade un remote llamado origin que apunta a la dirección original;
3. descarga todos los objetos y referencias, el equivalente a git fetch;
4. crea las ramas remotas origin/main, origin/develop, etc.;
5. crea la rama local por defecto (normalmente main), la vincula a origin/main y despliega los archivos.

Por eso, tras el clon no hace falta configurar git remote a mano: git push y git pull funcionan de inmediato.

git remote -v
origin  https://github.com/username/project.git (fetch)
origin  https://github.com/username/project.git (push)

Clonar por HTTPS o por SSH

Para leer proyectos abiertos de otras personas basta con HTTPS. Para tus repositorios, en los que haces push con frecuencia, SSH es más cómodo:

git clone git@github.com:username/project.git

Si ya clonaste por HTTPS y quieres pasar a SSH, no hace falta volver a descargarlo:

git remote set-url origin git@github.com:username/project.git

Cómo clonar en una carpeta concreta

El segundo argumento es el nombre o la ruta del directorio de destino:

# En una carpeta con otro nombre
git clone https://github.com/username/project.git my-copy

# En la carpeta actual (debe estar vacía)
git clone https://github.com/username/project.git .

Si la carpeta de destino existe y no está vacía, Git se negará: fatal: destination path 'project' already exists and is not an empty directory.

Cómo clonar una rama específica

Por defecto, después del clon estás en la rama por defecto del repositorio remoto. Para empezar directamente en otra, usa -b (--branch):

git clone -b develop https://github.com/username/project.git

Ojo: así se descargan todas las ramas, simplemente acabarás en develop. Si solo quieres una rama sin las demás, añade --single-branch:

git clone -b develop --single-branch https://github.com/username/project.git

La opción -b también acepta el nombre de una etiqueta; entonces obtendrás el estado del proyecto en el momento de esa versión (en modo detached HEAD):

git clone -b v2.1.0 --depth 1 https://github.com/username/project.git

Dónde están las demás ramas después del clon

Los principiantes se sorprenden: git branch solo muestra main. Las otras ramas se han descargado como remotas y puedes verlas así:

git branch -a

* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/develop
  remotes/origin/feature/login

Para empezar a trabajar en una de ellas basta con cambiar usando el nombre corto: Git creará solo una rama local que sigue a la remota:

git switch develop

Clon superficial: --depth para repositorios grandes

En proyectos antiguos el historial puede ocupar gigabytes. Si solo necesitas el código actual (por ejemplo, en CI o simplemente para compilar el proyecto), descarga los últimos commits:

git clone --depth 1 https://github.com/username/big-project.git

La opción --depth implica --single-branch, así que solo llegan la rama por defecto y un commit. Si más adelante necesitas el historial completo, puedes descargar el resto:

git fetch --unshallow

También puedes indicar otra profundidad, como --depth 50, o limitar el historial por fecha con --shallow-since=2025-01-01. Para el desarrollo activo, un clon superficial es incómodo: git log, git blame y las búsquedas en el historial quedarán incompletos.

Clon parcial: --filter

Una alternativa para monorepositorios enormes es descargar el historial de commits y traer el contenido de los archivos bajo demanda:

git clone --filter=blob:none https://github.com/username/monorepo.git

Así conservas el historial completo para log y para cambiar de rama, pero ahorras tráfico y espacio. Necesita soporte del servidor; GitHub y GitLab lo ofrecen.

Clon espejo y migración de un repositorio

Un clon normal trae las ramas como remotas y no copia las referencias internas del servidor. Para migrar un proyecto a otro hosting o hacer una copia de seguridad idéntica se usa --mirror:

git clone --mirror https://github.com/username/project.git
cd project.git
git push --mirror git@gitlab.com:username/project.git

Un espejo es un repositorio bare sin archivos de trabajo, en el que todas las ramas y etiquetas se guardan como locales. git push --mirror las envía completas al nuevo servidor y el historial se migra sin pérdidas. Ten en cuenta que las issues, los pull requests y la configuración del hosting no se trasladan así: son datos del servicio, no de Git.

La opción parecida --bare también crea un repositorio sin directorio de trabajo, pero solo copia ramas y etiquetas. Sirve para montar un repositorio central en tu propio servidor a partir de un proyecto existente.

Clonar con submódulos

Si el proyecto usa git submodules, por defecto sus carpetas quedarán vacías. Para descargarlo todo de una vez:

git clone --recurse-submodules https://github.com/username/project.git

Si ya clonaste sin la opción, descarga los submódulos después:

git submodule update --init --recursive

git clone, fork y descargar ZIP

Fork y clone no compiten: en open source primero se hace el fork en la web, luego se clona tu propio fork y se añade el original como segundo remote:

git clone git@github.com:me/project.git
cd project
git remote add upstream https://github.com/author/project.git
git fetch upstream

Errores frecuentes de git clone

«Repository not found»

Hay una errata en la dirección o el repositorio es privado y no tienes acceso. Con los repositorios privados GitHub responde a propósito «not found» en lugar de «acceso denegado». Revisa la dirección y que hayas iniciado sesión con la cuenta correcta.

«Permission denied (publickey)»

Clonas por SSH pero la clave no está configurada. Comprueba con ssh -T git@github.com, añade la clave pública en la configuración de la cuenta o clona temporalmente por HTTPS.

«Authentication failed» por HTTPS

Escribiste la contraseña de la cuenta. Hace tiempo que GitHub exige un Personal Access Token en lugar de la contraseña para operar con Git por HTTPS. Si Git guardó credenciales incorrectas, bórralas en el gestor de credenciales del sistema.

Corte en un repositorio grande

Errores como early EOF o RPC failed suelen deberse a una red inestable y al tamaño. Ayuda un clon superficial con --depth 1 seguido de git fetch --unshallow, o clonar por SSH.

Problemas con los finales de línea en Windows

Después del clon todos los archivos aparecen «modificados»: así se manifiesta la conversión CRLF/LF. Configura git config --global core.autocrlf true en Windows (o input en Linux y macOS) y, mejor aún, define reglas en el .gitattributes del proyecto.

Qué hacer justo después de clonar

El clon está listo, pero antes de tocar el código merece la pena dedicar un par de minutos a prepararse. Así evitarás los problemas típicos del primer día con un proyecto ajeno.

1. Lee README y CONTRIBUTING. Suelen explicar cómo instalar dependencias, ejecutar los tests y cómo se nombran las ramas en el proyecto.
2. Comprueba la rama y el estado. git status y git log --oneline -5 te dirán dónde estás y cuáles son los últimos cambios.
3. Crea tu propia rama. No trabajes directamente en main: git switch -c feature/my-task.
4. Revisa el autor de los commits. Si en el ordenador tienes varias cuentas (personal y de trabajo), define el e-mail para ese repositorio concreto sin --global: git config user.email "you@company.com".
5. Instala las dependencias. Carpetas como node_modules o venv no se guardan en el repositorio, se crean en local: npm install, pip install -r requirements.txt, etc.

Cómo mantener el clon actualizado

Se clona una sola vez. Después, los nuevos commits de tus compañeros se traen desde el mismo origin:

# Ver qué hay de nuevo en el servidor sin cambiar nada
git fetch
git log --oneline main..origin/main

# Integrar los cambios en la rama actual
git pull

La costumbre de hacer primero git fetch y mirar qué ha llegado evita conflictos inesperados. No hace falta volver a clonar el proyecto «para actualizarlo»: así se pierden las ramas locales y el trabajo sin commit.

Chuleta de git clone

Resumen

git clone descarga el repositorio completo y configura en el acto la conexión con el servidor mediante origin, así que después puedes hacer commit, push y pull sin configurar nada más. Para tus proyectos usa SSH, para los grandes --depth o --filter y para una rama concreta -b. El trabajo con repositorios remotos, push, pull y fetch se practica en el curso de Git.