Flujo de trabajo colaborativo

Para trabajar entre varios en un repositorio, existen dos grandes modelos de colaboración. La elección depende sobre todo de quién tiene derecho a escribir en el repositorio.

En empresa, se usa casi siempre la rama compartida (visto en las lecciones 01–03). Para contribuir a un proyecto open source del que no se es miembro, se pasa por el fork.

Un fork es una copia personal de un repositorio en tu cuenta GitHub. Ahí tienes todos los derechos, sin tocar el original. El clone, por su parte, descarga un repositorio en tu máquina local.

No confundir:

# 1. El fork se hace con el botón "Fork" en GitHub (o la CLI)
gh repo fork projet/app --clone

# Equivalente manual tras un fork:
# 2. Clonar SU fork
git clone https://github.com/vous/app.git
cd app

# 3. Verificar el remote
git remote -v
# origin  https://github.com/vous/app.git (fetch/push)

El fork es tu «caja de arena»: puedes romperlo todo sin riesgo para el proyecto original. Cuando tu trabajo está listo, una pull request lo propone al mantenedor, que decide aceptarlo.

🔧 Mini-ejercicio — Con gh, haz fork del repositorio projet/app y clónalo en tu máquina en un solo comando.

Mientras trabajas, el repositorio original evoluciona. Tu fork no se actualiza solo. Hay que añadir un remote upstream que apunte al original, y luego recuperar sus cambios con regularidad.

# 1. Declarar el repositorio original como 'upstream'
git remote add upstream https://github.com/projet/app.git

# 2. Recuperar sus últimos cambios
git fetch upstream

# 3. Actualizar su main local
git switch main
git merge upstream/main

# 4. Empujar a su propio fork
git push origin main

Sincronizar pronto y a menudo con upstream evita que tu fork «derive» del proyecto. Cuanto más esperas, más conflictos habrá el día de la PR.

🔧 Mini-ejercicio — Escribe el comando para declarar el repositorio original https://github.com/projet/app.git como remote upstream.

Una issue es un ticket: un lugar para señalar un bug, proponer una funcionalidad o hacer una pregunta. Es el sistema de seguimiento de un proyecto GitHub.

Lo que se pone en una buena issue de bug:

# Crear una issue desde el terminal
gh issue create --title "Crash au clic sur Exporter" \
  --body "Étapes : 1) ouvrir X 2) cliquer Exporter → l'app se ferme."

# Listar las issues abiertas
gh issue list

# Ligar una PR a una issue: en la descripción de la PR
#   Closes #42   → cierra automáticamente la issue #42 al fusionar

Los labels organizan las issues: bug, enhancement, documentation, good first issue, help wanted…

Las issues transforman el «habría que corregir esto un día» en tareas trazables y discutibles. Ligar una PR con Closes #N cierra la issue automáticamente al fusionar: cero olvidos.

🔧 Mini-ejercicio — Con gh, crea una issue titulada «Crash au clic sur Exporter».

Más allá de los comandos, colaborar con eficacia se apoya en convenciones compartidas. Estas son las que marcan la diferencia.

El estándar de los «Conventional Commits», muy extendido:

git commit -m "feat: ajout de l'export CSV"
git commit -m "fix: corrige le crash au login"
git commit -m "docs: mise à jour du README"
git commit -m "refactor: simplifie le service de paiement"

Un equipo que comparte convenciones no necesita concertarse sin cesar: el código, los commits y las ramas «hablan» la misma lengua. Eso es la fluidez colaborativa.

🔧 Mini-ejercicio — Acabas de añadir el export CSV. Escribe el mensaje de commit en formato Conventional Commits.

Question 1

¿Qué es un fork?

a) Una fusión de dos ramas

b) Una copia personal de un repositorio en tu cuenta GitHub

c) Un tipo de conflicto

d) Un borrado del historial

Question 2

¿Cuál es la diferencia entre origin y upstream en el modelo fork & pull?

a) Ninguna, son sinónimos

b) origin es tu fork, upstream es el repositorio original

c) origin es local, upstream está en tu disco

d) upstream sirve para borrar ramas

Question 3

¿Para qué sirve una issue?

a) Para compilar el código

b) Para señalar un bug, proponer una funcionalidad o discutir una tarea

c) Para fusionar automáticamente las ramas

d) Para clonar un repositorio

Question 4

¿Qué hace Closes #42 en la descripción de una pull request?

a) Borra el commit 42

b) Cierra automáticamente la issue #42 cuando se fusiona la PR

c) Abre una issue nueva

d) Cancela la PR

Question 5

¿Qué significa el prefijo de commit fix: en los Conventional Commits?

a) Una funcionalidad nueva

b) Una corrección de bug

c) Documentación

d) Un test

Corrigé

1. b — Un fork es una copia personal del repositorio en tu cuenta GitHub.
2. b — origin es tu fork; upstream es el repositorio original.
3. b — Una issue es un ticket: bug, idea o discusión, organizada con labels.
4. b — Closes #42 cierra la issue #42 al fusionar la PR.
5. b — fix: = corrección de bug; feat: = funcionalidad; docs: = documentación.

Consigna

Quieres contribuir a un proyecto open source projet/app del que no eres miembro. Realiza el ciclo completo del modelo fork & pull:

1. Haz fork y clona el repositorio.
2. Añade el remote upstream y sincroniza tu main.
3. Crea una rama, haz un commit (corrigiendo la issue #8) y empújala a tu fork.
4. Abre una pull request hacia el repositorio original ligando la issue.

Corrección

# 1. Fork + clone
gh repo fork projet/app --clone
cd app

# 2. Añadir upstream y sincronizar
git remote add upstream https://github.com/projet/app.git
git fetch upstream
git switch main
git merge upstream/main
git push origin main

# 3. Ramificar, commit, empujar
git switch -c fix/correction-typo-readme
# ... corrección del archivo README ...
git commit -am "fix: corrige une faute dans le README"
git push -u origin fix/correction-typo-readme

# 4. Abrir la PR hacia el repositorio ORIGINAL
gh pr create --repo projet/app \
  --base main --head vous:fix/correction-typo-readme \
  --title "fix: faute de frappe dans le README" \
  --body "Corrige une coquille. Closes #8"

Resultado esperado:

$ git remote -v
origin    https://github.com/vous/app.git (push)
upstream  https://github.com/projet/app.git (fetch)

La PR parte de tu rama (vous:fix/...) hacia el main del repositorio original. El mantenedor la relee y decide fusionar: acabas de contribuir al open source sin haber tenido nunca derecho de escritura en el proyecto.

Puntos a recordar

1. Dos modelos: rama compartida (equipo interno) y fork & pull (open source).
2. Fork = copia en tu cuenta; clone = copia en tu máquina.
3. origin = tu fork; upstream = el repositorio original, que hay que sincronizar con regularidad.
4. Las issues trazan bugs, ideas y tareas; Closes #N liga y cierra al fusionar.
5. Buenas prácticas: commits claros, ramas cortas, PR pequeñas, main estable.
6. Conventional Commits (feat:, fix:, docs:…) estandarizan los mensajes.

A continuación

Este módulo 02 ha terminado: ya sabes ramificar, fusionar, abrir pull requests y colaborar a gran escala. El módulo 03 sigue el recorrido DevOps con la integración continua (CI/CD), que automatizará tests y despliegues a partir de esas mismas pull requests.