La magia de los Pull Requests

1. Del merge a la propuesta: ¿para qué sirven los Pull Requests?

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

Para evitarlo, en el desarrollo en equipo se adopta otro enfoque. En lugar de fusionar los cambios inmediatamente, creas una propuesta de fusión. Esta propuesta se llama Pull Request (abreviado PR) o, en algunas plataformas, Merge Request.

Pull Request — es una solicitud oficial: «Por favor, haced pull de mis cambios desde mi rama y haced merge en la rama principal». Pero no es solo una petición, sino todo un espacio para debate, revisión y mejora del 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 de trabajo típico al crear una nueva funcionalidad.

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

De lo contrario, todos tus commits locales «olvidados» de main acabarán por accidente en el nuevo Pull Request, creando confusión para tus compañeros.

Paso 1. Crea una rama para la nueva tarea.

Como antes, cualquier trabajo nuevo empieza creando una rama independiente. Supongamos que queremos añadir al proyecto un archivo con reglas para colaboradores. Crearemos la rama feature/add-contribution-guide.

Paso 2. Realiza los cambios y envía tu rama a GitHub.

En la nueva rama crea el archivo CONTRIBUTING.md (después de crearlo pulsa Add) y escribe en él un mensaje para otros desarrolladores. Después, 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, tienes que enviar (push) tu nueva rama a GitHub.

3. Creación de 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 de la IDE está la pestaña Pull Requests. Ábrela y haz clic en el icono + para crear un nuevo PR.

Paso 2. Rellena los datos del PR.

La IDE abrirá automáticamente una interfaz cómoda para crear el Pull Request. Tu tarea es completarla correctamente. Veamos los campos principales:

1. Título: la IDE suele poner aquí el nombre de la rama, pero es una mala práctica. El título debe ser breve, claro y reflejar la esencia de los cambios, como un buen mensaje de commit.
2. Descripción: aquí explicas qué y para qué has hecho.
3. Revisores: aquí eliges a uno o varios colegas que deben revisar tu código. En el proyecto de aprendizaje omitiremos este paso, pero en el trabajo real es obligatorio.
4. Asignados: normalmente te seleccionas a ti mismo. Esto significa que eres el autor y el principal responsable de esta tarea y de aplicar las correcciones tras la revisión.

Una vez rellenados todos los campos, pulsa Create Pull Request sin dudarlo.

4. Revisión de código: comprobación y debate

Tras crear el PR comienza la etapa más importante — la revisión de código (code review). Tus compañeros pueden abrir tu PR, revisar todos los cambios y dejar comentarios.

Puedes ver todas las conversaciones 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 tienes que crear un PR nuevo. Simplemente realiza los cambios necesarios en el código en la misma rama, haz un nuevo commit y envíalo (push). El Pull Request en GitHub se actualizará automáticamente añadiendo tus nuevos commits.

5. Finalización del trabajo: merge y eliminación de la rama

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

Paso 1. Merge

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

Paso 2. Eliminación de 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 olvides eliminar también la copia local de la rama en tu IDE para mantener el orden. Puedes hacerlo desde el mismo menú de gestión de ramas.

6. Tres reglas del commit

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

Regla 1: escribe mensajes comprensibles siguiendo 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 absolutamente inútil. El estándar más popular se llama Conventional Commits. Propone la siguiente estructura:

<tipo>: <descripción breve>

Tipo es una palabra corta que describe la categoría de tus cambios:

• feat: (feature) — para nueva funcionalidad.
• fix: — para corregir un error.
• docs: — para cambios en la documentación.
• style: — para ajustes de formato que no afectan a la lógica del código.
• refactor: — para cambios en el código que no añaden nueva funcionalidad ni corrigen errores.
• test: — para añadir o corregir pruebas.
• chore: — para tareas rutinarias no relacionadas con el código (actualización de dependencias, configuración de la compilación).

Ejemplos:

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

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

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

No intentes meter en un solo commit la corrección de un bug, la adición de una nueva función y el refactor de código antiguo. Un commit así es muy difícil de revisar y casi imposible de revertir sin dolor si algo sale mal.

Cada commit debe resolver una única tarea concreta.

• Mal: un único commit con el mensaje «Update user page», que añade el campo para el avatar, corrige un error en 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 enfocados son mucho más fáciles de entender y gestionar.

Regla 3: un commit no debe romper el proyecto

Cada commit en la rama principal debe dejar el proyecto en estado funcional. Antes de crearlo, al menos debes asegurarte de que el código compila. Pero ¿cómo asegurarte de que no has roto algo en otra parte del sistema? Confiar solo en la comprobación manual es arriesgado.

Aquí es donde entra en juego la automatización. En este curso no configuraremos 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 sus pruebas. Luego configuras un flujo (workflow) especial directamente en GitHub. Ahora, en cuanto haces push a tu Pull Request, ocurre la magia:

1. GitHub Actions detecta ese evento y lanza tu flujo.
2. Compila el proyecto automáticamente y ejecuta todas las pruebas.
3. Si todas las pruebas pasan correctamente, junto a tu commit en GitHub aparece una marca verde. Es la señal para todo el equipo de que tus cambios son seguros.
4. Si al menos una prueba falla, verás una cruz roja. Fusionar un PR así en la rama principal está terminantemente prohibido.

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

            subgraph Workflow
            C -- "Inicio" --> D[Ejecución de pruebas]
            D --> E[Exitoso]
            D --> F[Fallido]
            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 las pruebas fallan, GitHub Actions puede enviar un correo a ti o a todo el equipo. Este enfoque crea una cultura en la que las pruebas no son una mera formalidad, sino una parte imprescindible del desarrollo, y cada uno es responsable de la calidad de su código.