La magia de los Pull Requests

1. De fusionar a proponer: ¿para qué sirven los Pull Requests?

En la lección anterior aprendimos a fusionar (merge) ramas en nuestro equipo local. Eso funciona bien cuando trabajas solo. Pero ¿qué pasa si en el proyecto trabaja todo un equipo? Si cada uno fusiona sus cambios directamente en la rama principal main, pronto habrá un caos: alguien puede añadir por error código con bugs, romper la build o borrar una parte importante del trabajo de un compañero.

Para evitar esto, en el desarrollo en equipo se usa otro enfoque. En vez de fusionar los cambios de inmediato, creas una propuesta de fusión. Esa propuesta se llama Pull Request (PR) o, en algunas plataformas, Merge Request.

Pull Request —es una petición oficial: "Por favor, haz pull de mis cambios desde mi rama y haz merge en la rama principal". Pero no es solo una petición: es una plataforma para discutir, revisar y mejorar el código antes de que llegue a main.

2. Flujo de trabajo estándar con Pull Request

Vamos a ver paso a paso cómo es el flujo típico al implementar una nueva funcionalidad.

Antes de crear una rama para una nueva tarea, asegúrate de haber enviado todos tus commits terminados (push) y de haber actualizado (Update Project) la rama principal main.

Si no, todos tus commits "olvidados" locales desde main pueden acabar accidentalmente en el nuevo Pull Request y crear confusión para tus compañeros.

Paso 1. Crea una rama para la nueva tarea.

Como antes, cualquier trabajo nuevo empieza creando una rama separada. Por ejemplo, queremos añadir un archivo con las reglas para los contribuyentes. Creamos la rama feature/add-contribution-guide.

Paso 2. Realiza cambios y sube tu rama a GitHub.

En la rama nueva crea el archivo CONTRIBUTING.md (después de crearlo haz clic en Add) y escribe un mensaje para otros desarrolladores. Luego haz Commit and Push con un mensaje claro, por ejemplo: docs: Add contribution guide.

¡Este es un paso clave! El Pull Request se crea a partir de una rama que ya existe en el servidor remoto. Por eso, antes de crear el PR, debes subir (push) tu nueva rama a GitHub.

3. Crear un Pull Request desde IntelliJ IDEA

Ahora que tu rama está en GitHub, puedes crear el Pull Request.

Paso 1. Abre la pestaña Pull Requests.

A la izquierda del IDE está la pestaña Pull Requests. Ábrela y haz clic en el ícono + para crear un PR nuevo.

Paso 2. Rellena los datos del PR.

La IDE te abrirá una interfaz cómoda para crear el Pull Request. Tu tarea es rellenarla bien. Vamos a ver los campos principales:

1. Título: la IDE a menudo pone el nombre de la rama, pero eso es mala práctica. El título debe ser breve, claro y reflejar la esencia del cambio, como un buen mensaje de commit.
2. Descripción: aquí explicas qué y por qué hiciste los cambios.
3. Reviewers: aquí eliges uno o varios colegas que deben revisar tu código. En un proyecto de práctica podemos saltar este paso, pero en trabajo real es obligatorio.
4. Assignees: normalmente pones aquí a ti mismo. Eso significa que eres el autor y el principal responsable de esta tarea y de aplicar los cambios después del review.

Cuando todos los campos estén completos, pulsa sin miedo Create Pull Request.

4. Code review: revisión y discusión

Después de crear el PR empieza la etapa más importante — el code review. Tus compañeros pueden abrir tu PR, ver todos los cambios y dejar comentarios.

Puedes ver todas las discusiones directamente en la IDE en la pestaña Pull Requests. Si alguien deja un comentario, recibirás una notificación.

¿Qué hacer si te piden cambios?

¡Muy sencillo! No hace falta crear un PR nuevo. Solo aplica los cambios necesarios en el mismo branch, haz otro commit y haz push. El Pull Request en GitHub se actualizará automáticamente con tus nuevos commits.

5. Finalizar el trabajo: merge y eliminación de la rama

Cuando todos los comentarios estén resueltos y el equipo apruebe tus cambios, se puede fusionar el Pull Request. Normalmente lo hace un desarrollador senior o tú mismo, si tienes permiso.

Paso 1. Merge

La fusión suele hacerse en el sitio de GitHub. Allí, bajo tu PR aparecerá un gran botón verde Merge pull request. Al pulsarlo, tu código pasará a formar parte de la rama principal main.

Paso 2. Eliminar la rama.

Después del merge tu rama feature ya no es necesaria y conviene eliminarla para no ensuciar el repositorio. GitHub te lo propondrá mostrando el botón Delete branch.

No te olvides de borrar también la copia local de la rama en tu IDE para mantener el orden. Eso se puede hacer desde el mismo menú de gestión de ramas.

6. Tres reglas para los commits

Un buen commit no es solo un mensaje correcto, sino también contenido correcto. Para que tu historial de cambios sea limpio, útil y profesional, sigue tres reglas simples.

Regla 1: escribe mensajes claros según un estándar

Tus commits son mensajes que envías a tu equipo y a tu yo del futuro. Un historial lleno de mensajes "fix" o "update" es inútil. El estándar más popular se llama Conventional Commits. Propone la siguiente estructura:

<tipo>: <descripción breve>

Tipo — una palabra corta que describe la categoría del cambio:

• feat: (feature) — para nueva funcionalidad.
• fix: — para corrección de bugs.
• docs: — para cambios en la documentación.
• style: — para ajustes de formato que no afectan la lógica.
• refactor: — para cambios en el código que no añaden funcionalidad ni corrigen bugs.
• test: — para añadir o corregir tests.
• chore: — para tareas rutinarias no relacionadas con el código (actualizar dependencias, configurar la build).

Ejemplos:

• Mal: fixed bug
• Bien: fix: Correct user login validation

• Mal: readme
• Bien: docs: Update installation instructions

Regla 2: un commit — un cambio lógico (Atomicidad)

No intentes meter en un solo commit la corrección de un bug, la nueva funcionalidad y el refactor de código antiguo. Ese commit es muy difícil de revisar y casi imposible de revertir sin daños si algo sale mal.

Cada commit debe resolver solo una tarea concreta.

• Mal: un commit con el mensaje "Update user page" que añade el campo de avatar, arregla la validación del nombre y cambia el color de los botones.
• Bien: tres commits distintos:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

Los commits pequeños y focalizados son mucho más fáciles de entender y manejar.

Regla 3: el commit no debe romper el proyecto

Cada commit en la rama principal debe dejar el proyecto en un estado funcional. Antes de crearlo debes al menos asegurarte de que el código compila. Pero ¿cómo estar seguro de que no rompiste algo en otra parte del sistema? Confiar solo en pruebas manuales es arriesgado.

Aquí entra la automatización. En este curso no vamos a configurar procesos automáticos, pero debes saber cómo funciona en proyectos reales. Los equipos modernos usan sistemas de integración continua (Continuous Integration, CI), como GitHub Actions.

¿Cómo funciona?

Escribes código y tests para él. Luego configuras un workflow directamente en GitHub. Ahora, cuando haces push a tu Pull Request, sucede la magia:

1. GitHub Actions detecta el evento y lanza tu workflow.
2. Éste automáticamente "build" el proyecto y ejecuta todos los tests.
3. Si todos los tests pasan, junto a tu commit en GitHub aparece una marca verde. Es una señal para todo el equipo de que tus cambios son seguros.
4. Si al menos un test falla, verás un aspa roja. Fusionar ese PR en la rama principal está estrictamente prohibido.

            graph LR
            subgraph GitHub
            A[Desarrollador] -- "push" --> B(Repositorio)
            B -- "Evento: push" --> C{GitHub Actions}
            end

            subgraph Workflow
            C -- "Lanzamiento" --> D[Ejecutar_tests]
            D --> E[Éxito]
            D --> F[Fallo]
            end

            subgraph Notifications
            F --> G((Email))
            G --> H[Desarrollador]
            G --> I[Equipo]
            end

            style F fill:#f99,stroke:#333,stroke-width:2px
            style G fill:#ccf,stroke:#333,stroke-width:2px
        

Se pueden configurar notificaciones. Si los tests fallan, GitHub Actions puede enviar un correo a ti o a todo el equipo. Este enfoque crea una cultura donde los tests no son una formalidad, sino una parte inseparable del desarrollo, y cada uno es responsable de la calidad de su código.