Fork vs clone en Git: cuándo usar cada uno

Clonas un repositorio de código abierto, arreglas un bug que te molestaba, haces git push, y Git te escupe un remote: Permission denied. Lo primero que piensas es que has metido mal las credenciales. No. Ese repositorio no es tuyo, y ese error es exactamente donde fork y clone dejan de sonar a lo mismo. Si llevas tiempo clonando repos sin pensarlo, este es el momento en que la palabra “fork” empieza a tener sentido.

¿Qué es un clone y dónde vive esa copia?

Un clone es una copia completa del repositorio descargada en tu máquina. Cuando ejecutas git clone, Git baja todo el historial, todas las ramas y todos los commits, y deja un directorio con el que puedes trabajar sin conexión. Si quieres repasar este paso en detalle, lo desmenuzo en clonar un repositorio de Git.

git clone https://github.com/usuario/proyecto.git

Esa copia no queda aislada. Git guarda una referencia al sitio del que la descargaste, y por convención la llama origin. Ese es el enlace entre tu copia local y el repositorio remoto. Lo puedes ver así:

git remote -v
# origin  https://github.com/usuario/proyecto.git (fetch)
# origin  https://github.com/usuario/proyecto.git (push)

Cuando haces git push, Git intenta subir tus commits a ese origin. Y aquí está el detalle que casi nadie te explica el primer día: que puedas descargar un repositorio no significa que puedas subir cambios a él. Leer y escribir son permisos distintos.

¿Qué es un fork y en qué se diferencia?

Un fork es una copia del repositorio entero dentro de tu propia cuenta de GitHub. Es, en la práctica, un repositorio nuevo que comparte el código y todo el historial con el original, pero que es tuyo: apunta a tu usuario, y tú tienes permiso de escritura sobre él.

La distinción importante es quién lo crea y dónde. git clone es un comando de Git que baja una copia a tu máquina. Un fork lo creas pulsando un botón en la interfaz de GitHub (o de GitLab, o de la plataforma que sea). No hay ningún git fork en la terminal, porque Git, la herramienta, no sabe nada de cuentas de usuario ni de plataformas. El concepto de fork vive en GitHub, no en Git.

Así que un fork y un clone operan en planos diferentes. El fork es un repositorio remoto en la nube, tuyo. El clone es la copia de trabajo que te bajas a tu portátil. En el flujo normal para contribuir a un proyecto ajeno vas a usar los dos, uno detrás del otro.

Por qué clonar no basta para contribuir a un repositorio ajeno

Clonar el repositorio original te deja mirar, pero no tocar. En el momento en que intentas devolver tus cambios al proyecto de otra persona, Git te frena con un error muy concreto:

git push origin main
# remote: Permission to original/proyecto.git denied to tu-usuario.
# fatal: unable to access 'https://github.com/original/proyecto.git/':
# The requested URL returned error: 403

Ese 403 no habla de tu red ni de tus claves. Lo que dice GitHub es que no formas parte de la lista de gente con acceso de escritura a original/proyecto. Y tiene todo el sentido: si cualquiera que clona un proyecto popular pudiera reescribir su rama principal, el código abierto duraría una tarde.

La primera vez que quise arreglar una errata en la documentación de una librería que usaba, me estampé contra este mismo 403. Clonar es la vía correcta para tu código y para el de tu equipo cuando tienes acceso. Para el código de un desconocido en internet, necesitas algo intermedio que sí sea tuyo. Ese algo es el fork.

Contribuir a un proyecto tiene dos caminos según de quién sea el repositorio: si tienes acceso directo, clonas y trabajas en ramas; si no lo tienes, pasas por un fork. Los dos caminos, con sus roles y permisos, los cubro entero en la guía de trabajar en equipo con Git y GitHub. Aquí nos centramos en el segundo.

El flujo completo: fork, clone, rama y pull request

El patrón para contribuir a un proyecto ajeno son cuatro movimientos encadenados: forkeas, clonas tu fork, trabajas en una rama y abres un pull request. Vamos uno a uno.

Primero, el fork. Entras en la página del proyecto original en GitHub y pulsas “Fork”. En unos segundos tienes https://github.com/tu-usuario/proyecto en tu cuenta, con permiso de escritura tuyo.

Segundo, clonas tu fork, no el original. Este es el paso donde más gente se equivoca:

# Clona TU fork (tu-usuario), no el repositorio original
git clone https://github.com/tu-usuario/proyecto.git
cd proyecto

Tercero, creas una rama para tu cambio. Nunca trabajes directamente sobre main. Una rama por cambio mantiene tu trabajo aislado y hace que el pull request sea limpio:

# Crea la rama y muévete a ella en un solo paso
git switch -c arregla-typo-readme

# ...editas los archivos, revisas con git status...
git add README.md
git commit -m "Corrige una errata en el README"

git switch -c crea la rama y te cambia a ella de una sola vez. Es la forma recomendada hoy: git switch está disponible desde Git 2.23 y la documentación oficial ya no lo marca como experimental. Un aviso sobre los commits: git commit -a solo prepara archivos que Git ya conoce. Si has creado un archivo nuevo, tienes que hacerle git add a mano, porque -a no toca lo que no está rastreado todavía.

Cuarto, subes la rama a tu fork:

git push origin arregla-typo-readme

Como origin apunta a tu fork, aquí no hay ningún 403: tienes permiso de escritura sobre tu propia copia. El commit ya vive en la nube, en tu cuenta.

El último paso ocurre en la web. Vas a tu fork en GitHub y verás un botón para abrir un pull request desde tu rama hacia el repositorio original. Ese pull request es la petición formal de “eh, he hecho este cambio, ¿lo quieres en tu proyecto?”. El dueño del original lo revisa, comenta si hace falta, y decide si lo fusiona. El pull request es el puente entre tu fork y el proyecto de destino, y es donde termina el viaje del código que has escrito. Si nunca has abierto uno, en qué es un pull request explico paso a paso cómo se crea y qué esperar de la revisión.

Antes de seguir, prueba a ordenar tú mismo el flujo. Este ejercicio te reta a colocar fork, clone, rama, push y pull request en el orden correcto:

Cargando ejercicio...

¿Qué es upstream y por qué lo necesitas?

upstream es un segundo remoto que apunta al repositorio original, para que puedas traerte sus novedades a tu fork. Y lo necesitas porque un fork no se actualiza solo. En el momento en que lo creas es una foto fija del original; si el proyecto avanza mañana, tu fork se queda con la versión de hoy hasta que tú lo pongas al día.

Recuerda que en tu clon origin apunta a tu fork. Necesitas añadir el original con otro nombre:

# Añade el repositorio original como un remoto llamado upstream
git remote add upstream https://github.com/original/proyecto.git

git remote -v
# origin    https://github.com/tu-usuario/proyecto.git (fetch)
# origin    https://github.com/tu-usuario/proyecto.git (push)
# upstream  https://github.com/original/proyecto.git (fetch)
# upstream  https://github.com/original/proyecto.git (push)

Con upstream configurado, ponerte al día es traer sus cambios y fusionarlos en tu rama:

# Descarga los commits nuevos del original
git fetch upstream

# Sitúate en tu main y fusiona lo que ha avanzado el original
git switch main
git merge upstream/main

Si empiezas tu rama a partir de un main actualizado, tu pull request no arrastrará conflictos tontos con cambios que el proyecto ya tenía. GitHub también ofrece un botón “Sync fork” en la interfaz que hace el equivalente sin tocar la terminal, útil cuando solo quieres alinear tu main sin bajarte nada al portátil.

¿Cuándo usar clone y cuándo fork?

La regla corta: si tienes permiso de escritura sobre el repositorio, clonas; si no lo tienes, forkeas y luego clonas tu fork. La pregunta que decide no es técnica, es de permisos.

	Clone	Fork
Dónde vive la copia	En tu máquina local	En tu cuenta de GitHub (en la nube)
Quién tiene permiso de escritura	Solo si lo tenías en el remoto original	Tú, siempre, sobre tu fork
¿Comando de Git o acción de GitHub?	Comando: git clone	Acción de GitHub (un botón), no hay git fork
Para qué sirve	Trabajar en un repositorio en tu equipo	Contribuir a un proyecto ajeno sin acceso
Cómo se crea	git clone <url> en la terminal	Botón “Fork” en la web del proyecto

Bajándolo a escenarios concretos:

Escenario	Qué haces
Es tu propio repositorio	Clonas y trabajas directamente; ya eres el dueño
Repositorio de tu equipo con acceso de escritura	Clonas y trabajas en ramas; nada de fork
Repositorio ajeno sin acceso (código abierto)	Forkeas, clonas tu fork, rama, push y pull request
Solo quieres leer o probar el código en local	Clonas y ya; sin fork, sin push

Fork y clone no compiten. En el flujo de código abierto los usas juntos: el fork te da un repositorio donde sí puedes escribir, y el clone te trae ese fork a tu máquina para trabajar.

Errores comunes al empezar con forks

Clonar el original y estrellarte contra el 403. Es el clásico. Clonas original/proyecto, haces tu cambio, intentas hacer push y aparece el Permission denied. La solución no pasa por pelearte con las credenciales: forkeas primero y clonas tu fork.

Forkear pero clonar la URL equivocada. Haces el fork correctamente y luego, por costumbre, clonas la URL del original en vez de la de tu fork. Todo parece ir bien hasta que haces push y otra vez el 403, o peor, trabajas convencido de que tus commits llegan a tu copia cuando ni siquiera estás conectado a ella. Comprueba siempre con git remote -v que tu origin es tu-usuario/proyecto.

Trabajar en main de tu fork. Técnicamente funciona, pero te complica la vida. Si haces tus cambios en main y luego quieres sincronizar con el original, tus commits y los suyos chocan en la misma rama. Una rama por cambio mantiene main limpio y sincronizable.

Olvidarte de upstream y quedarte con un fork fósil. Nadie te avisa de que tu fork se ha quedado atrás. Semanas después intentas contribuir sobre una base vieja y el pull request llega lleno de conflictos. El fork no se actualiza solo cuando el original avanza; hay que sincronizarlo a mano o con el botón “Sync fork”.

Checklist para contribuir a un proyecto ajeno

• Has hecho fork del proyecto en GitHub antes de clonar
• Has clonado la URL de tu fork (tu-usuario/...), no la del original
• git remote -v muestra origin apuntando a tu fork
• Trabajas en una rama creada con git switch -c, no en main
• Has añadido upstream apuntando al repositorio original
• Tu rama parte de un main sincronizado con git fetch upstream
• Abres el pull request desde tu rama hacia el repositorio original

Practica el flujo completo

Leer el flujo una vez no es lo mismo que tenerlo en los dedos. En el curso Git de cero a profesional haces tú el ciclo entero, fork, clone, rama y pull request, sobre repositorios reales y con correcciones al momento, hasta que contribuir a un proyecto ajeno deja de darte respeto.

Un concepto nuevo cada semana

Suscribirme

Preguntas Frecuentes

¿Un fork es lo mismo que una rama?

No. Una rama vive dentro de un mismo repositorio y sirve para separar líneas de trabajo. Un fork es un repositorio entero aparte, en tu cuenta, con sus propios permisos. De hecho, dentro de tu fork vas a crear ramas igual que en cualquier repositorio.

¿Cuál es la diferencia práctica entre fork y clone si solo quiero leer el código?

Si solo quieres leer o ejecutar el proyecto en local, te basta con un clone; el fork no aporta nada en ese caso. El fork solo empieza a hacer falta cuando quieres devolver cambios a un proyecto donde no tienes permiso de escritura.

¿Puedo hacer fork de un repositorio privado?

Sí, siempre que tengas acceso a ese repositorio privado y siempre que el repositorio (o la organización dueña) tenga habilitado el forking, porque se puede desactivar por política. El flujo de fork, clone, rama y pull request es idéntico; lo único que cambia es que el repositorio y tu fork no son públicos.

¿Cómo mantengo mi fork al día con el original?

Añades el original como remoto upstream con git remote add upstream <url>, traes sus cambios con git fetch upstream y los fusionas en tu rama con git merge upstream/main. Si prefieres no tocar la terminal, el botón “Sync fork” de GitHub alinea tu main con el original desde la web.

¿Necesito hacer fork si tengo permiso de escritura en el repo del equipo?

No. Si ya tienes acceso de escritura, el fork sobra: clonas el repositorio directamente y trabajas en ramas, que es el flujo normal dentro de un equipo. El fork es la vía para cuando no tienes ese acceso.

¿Se puede clonar un fork en varias máquinas?

Sí. Tu fork es un repositorio remoto en GitHub, así que puedes clonarlo en tu portátil, en tu equipo de casa y donde quieras. Cada clone es una copia local independiente; todas empujan al mismo fork con git push origin.