Pull solicitudes

Una pull request (PR), también llamada merge request en GitLab, es una solicitud de integración: «aquí está mi trabajo en una rama, por favor reléelo y luego fusiónalo en main». Es el punto de encuentro entre el código y el equipo.

Una PR no es solo un botón «fusionar». Es un espacio de discusión alrededor del código: comentarios, sugerencias, tests automáticos, validación. Ahí se juega la calidad.

Antes de abrir una PR, hay que haber empujado su rama a GitHub.

Etapa 1 — Empujar la rama:

git switch feature/recherche
git push -u origin feature/recherche

Etapa 2 — Abrir la PR (dos opciones):

• En la interfaz de GitHub: aparece una banda «Compare & pull request»; se hace clic, se elige la rama base (main) y la rama comparada (feature/recherche).
• En la línea de comandos con GitHub CLI:

# Crea la PR sin salir del terminal
gh pr create --base main --head feature/recherche \
  --title "Ajout de la recherche" \
  --body "Implémente la barre de recherche avec filtres."

Una buena descripción de PR contiene:

El título y la descripción los leen humanos con prisa. Sé explícito: «Corrige el crash al login» vale mil veces más que «fix bug».

🔧 Mini-ejercicio — Desde la rama actual feature/recherche, crea una pull request hacia main con gh, dando un título claro.

gh pr create --base main --head feature/recherche \
  --title "Ajout de la recherche" --body "Implémente la barre de recherche."

La revisión de código (code review) es el corazón de la PR: uno o varios compañeros leen las modificaciones, hacen preguntas, sugieren mejoras y acaban por aprobar o pedir cambios.

Los tres veredictos posibles en GitHub:

Del lado del autor, tras los comentarios, se corrige y se vuelve a empujar: la PR se actualiza sola.

# Corregir tras la revisión
git switch feature/recherche
# ... modificaciones ...
git commit -am "Prise en compte des retours de revue"
git push          # la PR se actualiza sola

Lo que mira un buen reviewer:

• ¿El código hace lo que pretende? (lógica correcta)
• ¿Es legible y mantenible?
• ¿Hay tests? ¿La CI está en verde?
• ¿Problemas de seguridad o de rendimiento?

La revisión de código no es un juicio de la persona, sino una mejora colectiva del producto. Se critica el código, nunca al autor. Y también se destaca lo que está bien hecho.

Una vez la PR aprobada y la CI en verde, se fusiona. GitHub propone tres métodos, que cambian la forma del historial.

# Fusionar desde el terminal con GitHub CLI
gh pr merge 42 --squash --delete-branch

Tras la fusión, se limpia:

# Borrar la rama remota (a menudo automático)
git push origin --delete feature/recherche

# Actualizar el local
git switch main
git pull origin main

# Borrar la rama local
git branch -d feature/recherche

El squash and merge es muy popular: una funcionalidad = un commit limpio en main. El historial se vuelve una lista legible de funcionalidades, y no un revoltijo de «wip», «fix typo», «oups».

🔧 Mini-ejercicio — Con gh, fusiona la PR número 42 en squash y borra la rama de paso. Escribe el comando.

Una PR eficaz es una PR pequeña, clara y testeada. Estas son las costumbres de los equipos performantes.

# Ligar automáticamente una issue en la descripción
gh pr create --title "Ajout export CSV" \
  --body "Permet d'exporter les données en CSV. Closes #57"

Una PR de 1 000 líneas recibe un «LGTM» (looks good to me) sin una relectura de verdad — nadie tiene el valor de leerlo todo. Una PR de 50 líneas recibe devoluciones valiosas. Pequeño = releído en serio.

🔧 Mini-ejercicio — ¿Qué palabra clave añades en la descripción de una PR para cerrar automáticamente la issue #57 al fusionar?

Question 1

¿Para qué sirve una pull request?

a) Para borrar una rama

b) Para pedir la relectura y la integración de una rama en otra

c) Para instalar Git

d) Para clonar un repositorio

Question 2

¿Qué hay que hacer antes de poder abrir una PR en GitHub?

a) Borrar main

b) Empujar su rama al repositorio remoto (git push)

c) Cerrar el terminal

d) Desactivar la CI

Question 3

¿Qué significa «Request changes» durante una revisión?

a) El código está aprobado

b) Hacen falta correcciones antes de la fusión

c) Se borra la PR

d) Se crea un repositorio nuevo

Question 4

¿Qué método de fusión aplasta todos los commits de la rama en uno solo?

a) Create a merge commit

b) Squash and merge

c) Rebase and merge

d) Cherry-pick

Question 5

¿Por qué privilegiar las pull requests pequeñas?

a) Consumen menos disco

b) Se releen más rápido y con más seriedad

c) GitHub las hace obligatorias

d) Evitan escribir tests

Corrigé

1. b — Una PR pide la relectura y luego la fusión de una rama (a menudo en main).
2. b — Hay que empujar la rama al remoto (git push) antes de abrir la PR.
3. b — «Request changes» exige correcciones; el autor las empuja y la PR se actualiza.
4. b — Squash and merge condensa todos los commits en uno solo en main.
5. b — Una PR pequeña se relee de verdad; una enorme recibe a menudo un LGTM vacío.

Consigna

Has terminado una funcionalidad en la rama feature/footer. Realiza el ciclo completo de una pull request con GitHub CLI (gh):

1. Empuja la rama.
2. Abre una PR hacia main con un título claro y un enlace de issue (Closes #12).
3. Una vez aprobada, fusiónala en squash y borra la rama.
4. Actualiza tu repositorio local.

Corrección

# 1. Empujar la rama
git switch feature/footer
git push -u origin feature/footer

# 2. Abrir la pull request
gh pr create --base main --head feature/footer \
  --title "Ajout du pied de page du site" \
  --body "Ajoute un footer responsive avec liens et mentions légales. Closes #12"

# 3. Tras la aprobación: fusión en squash + borrado de la rama
gh pr merge --squash --delete-branch

# 4. Actualizar el local
git switch main
git pull origin main
git branch -d feature/footer

Resultado esperado:

$ git log --oneline -1
a1b2c3d Ajout du pied de page du site (#13)

El número entre paréntesis (#13) lo añade GitHub automáticamente: es el número de la PR. Hacer clic lleva a toda la discusión de revisión. Trazabilidad total.

Puntos a recordar

1. Una pull request pide la relectura y luego la fusión de una rama: es un espacio de discusión.
2. Crear una PR: empujar la rama, luego abrirla vía la interfaz o gh pr create.
3. La revisión de código acaba en Approve, Request changes o Comment; se critica el código, no al autor.
4. Tres métodos de fusión: merge commit, squash and merge, rebase and merge.
5. Buenas prácticas: PR pequeñas, un solo tema, CI verde, issue ligada.
6. Tras la fusión: borrar la rama y actualizar el local.

A continuación

Dominas el ciclo de contribución en tu repositorio. La lección 04 — Flujo de trabajo colaborativo abre la colaboración más amplia: fork, clone, issues y buenas prácticas de equipo.