Hasta ahora hemos trabajado siempre con repositorios que son nuestros. Pero en el mundo real existe otro escenario muy habitual: encuentras un proyecto de otra persona en GitHub, quieres mejorar algo, y quieres que esa mejora llegue al proyecto original.
Cuando quieres mejorar un proyecto open source en GitHub, podrías pensar en pedir permiso de escritura al repositorio original y crear una rama para hacer tus cambios. Pero esto no sería muy práctico: ¿por qué el desarrollador original debería confiar en cualquiera que se lo pida? Si todo el mundo tuviera acceso directo, sería un coladero para cambios maliciosos o de baja calidad.
Por eso GitHub utiliza el sistema de forks.
Un fork es básicamente una copia del repositorio original en tu propia cuenta. A partir de esa copia puedes hacer todos los cambios que quieras sin afectar al proyecto original. Cuando crees que tu mejora está lista, puedes enviar una Pull Request (PR) desde tu fork al repositorio original.
De esta forma, el desarrollador del proyecto puede revisar los cambios y decidir si integrarlos o no. Esto permite hacer contribuciones de forma segura y controlada.
Además, los forks también sirven para otro caso: cuando quieres tomar un proyecto como base y desarrollar tu propia variante. Un ejemplo clásico es Underscore.js, cuyo fork evolucionó hasta convertirse en Lodash.
En resumen, el fork permite que cualquiera experimente, mejore o adapte un proyecto sin comprometer el repositorio original, mientras que el mantenedor conserva el control sobre qué cambios se incorporan.
Cuando haces un fork de un repositorio, GitHub crea una copia completa de ese repositorio en tu propia cuenta. Es tuya, puedes hacer en ella lo que quieras sin afectar al original.
La diferencia con clonar es importante:
- Clonar descarga el repositorio en tu máquina, pero el repositorio sigue siendo de otra persona en GitHub.
- Hacer fork crea una copia del repositorio en tu cuenta de GitHub. A partir de ahí, ese repositorio también es tuyo en la nube.
El flujo habitual es: fork → clonar tu fork → trabajar → proponer los cambios al original.
Imagina que encuentras en GitHub un proyecto que te parece interesante y detectas que falta algo en el README. Quieres añadirlo y proponer el cambio al autor.
El repositorio original es de otra persona:
https://github.com/otro-usuario/proyecto-ejemplo
Tú no tienes permisos para modificarlo directamente. Pero puedes hacer un fork.
Entra en el repositorio que quieres forkear y haz clic en el botón Fork que aparece arriba a la derecha.
GitHub te pregunta en qué cuenta quieres crear el fork. Seleccionas la tuya y confirmas.
En unos segundos GitHub crea una copia del repositorio en tu cuenta. Fíjate en la URL: ahora es tuya.
https://github.com/tu-usuario/proyecto-ejemplo
Y justo debajo del nombre del repositorio, GitHub indica de dónde viene:
Ahora clonamos nuestro fork, no el original. Hacemos clic en el botón Code de nuestro fork y copiamos la URL.
git clone https://github.com/tu-usuario/proyecto-ejemplo.git
cd proyecto-ejemploComprobamos los remotos configurados:
git remote -vorigin https://github.com/tu-usuario/proyecto-ejemplo.git (fetch)
origin https://github.com/tu-usuario/proyecto-ejemplo.git (push)origin apunta a nuestro fork. Bien.
Hasta ahora solo tenemos origin, que es nuestro fork. Pero el repositorio original sigue existiendo y puede recibir cambios de su autor mientras nosotros trabajamos.
Para poder sincronizarnos con el original en el futuro, lo añadimos como un segundo remoto. Por convención se llama upstream:
git remote add upstream https://github.com/otro-usuario/proyecto-ejemplo.gitVerificamos:
git remote -vorigin https://github.com/tu-usuario/proyecto-ejemplo.git (fetch)
origin https://github.com/tu-usuario/proyecto-ejemplo.git (push)
upstream https://github.com/otro-usuario/proyecto-ejemplo.git (fetch)
upstream https://github.com/otro-usuario/proyecto-ejemplo.git (push)Ahora tenemos dos remotos:
origin— nuestro fork, donde podemos hacer push.upstream— el repositorio original, del que podemos descargar cambios pero al que no podemos hacer push directamente.
Nunca trabajamos directamente en main. Creamos una rama para nuestro cambio:
git switch -c mejora/readmeEditamos el README:
code README.mdHacemos el commit:
git add README.md
git commit -m "Añade sección de instalación al README"git push -u origin mejora/readmeTo https://github.com/tu-usuario/proyecto-ejemplo.git
* [new branch] mejora/readme -> mejora/readmeLa rama ya está en nuestro fork en GitHub.
Volvemos a GitHub. Al entrar en nuestro fork, veremos un aviso de que acabamos de subir una rama con un botón de Compare & pull request. Hacemos clic.
GitHub nos lleva al formulario para crear el Pull Request. Fíjate en la parte superior: está comparando tu rama con el repositorio original, que es exactamente lo que queremos.
Rellenamos:
- Título: una frase clara de lo que aporta el cambio.
- Descripción: explicamos qué hemos cambiado y por qué.
Hacemos clic en Create pull request.
Ahora el autor del repositorio original recibe una notificación. Puede revisar el cambio, pedir modificaciones o aceptarlo. Si lo acepta, tu commit pasará a formar parte del proyecto original.
Si el proyecto original sigue avanzando mientras trabajas en tu fork, puedes descargar esos cambios con upstream:
git switch main
git pull upstream main
git push origin mainEsto trae los cambios del repositorio original a tu main local y los sube a tu fork para mantenerlo al día.
El fork es el mecanismo que hace posible que miles de personas contribuyan a un mismo proyecto sin pisarse. Cada uno trabaja en su copia, propone cambios mediante Pull Requests y el autor del proyecto decide qué entra y qué no.