En este artículo verá qué es un Pull Request (PR), por qué es una herramienta para discutir cambios, y aprenderá a crear y revisar PR directamente desde el IDE. De paso veremos tres reglas de un buen commit. Es una base importante: Claude Code puede preparar y comentar un pull request por usted, y para aprovecharlo con criterio hay que entender qué es y para qué sirve.
Los ejemplos y las capturas de pantalla corresponden a un IDE de JetBrains; los nombres y la ubicación de las acciones pueden variar en su versión. Para los ejercicios, use un repositorio de práctica aparte. En un proyecto de trabajo, siga las reglas de ese proyecto sobre ramas, commits y envío de cambios.
Para qué sirven los Pull Requests
En un equipo conviene discutir los cambios antes de que entren en una rama común. Un pull request reúne en un solo sitio el diff propuesto, las observaciones y los resultados de las comprobaciones. También se usa en proyectos personales, cuando uno quiere revisar su propio trabajo antes de fusionarlo.
En un flujo con PR, primero se crea una propuesta de fusión. En GitHub se llama Pull Request, y en algunas otras plataformas, Merge Request. El orden concreto del trabajo lo decide el equipo.
Un Pull Request es una petición formal: "por favor, tomen (pull) mis cambios de mi rama e incorpórenlos (merge) a la rama principal". Pero no es solo una petición, sino todo un espacio para discutir, revisar y mejorar el código antes de que llegue a main.
Claude Code puede preparar el título, la descripción y un análisis del PR, por ejemplo con GitHub CLI. Revise primero el borrador. Crear un PR o publicar un comentario ya es escribir en GitHub, y eso se hace solo cuando usted lo encarga.
El flujo de trabajo habitual con un Pull Request
Veamos paso a paso cómo es el proceso típico al desarrollar una nueva funcionalidad.
Antes de crear la rama, compruebe la rama de partida y qué commits tiene respecto a la rama de destino en GitHub. En el nuevo PR no deben colarse commits locales ajenos a la tarea. No los envíe automáticamente para "sincronizar": elija la base correcta para la tarea y guarde el trabajo anterior por separado.
Paso 1. Cree una rama para la nueva tarea. En el proceso con PR que mostramos aquí, el trabajo empieza en una rama aparte. Supongamos que queremos añadir un archivo con normas para quienes contribuyen al proyecto: creamos la rama feature/add-contribution-guide.
Paso 2. Haga los cambios y envíe la rama a GitHub. En la nueva rama, cree el archivo CONTRIBUTING.md (después de crearlo, pulse Add) y escriba en él un mensaje para los demás desarrolladores. Luego haga Commit and Push con un mensaje claro, por ejemplo docs: Add contribution guide.
Este es el paso clave. Un Pull Request se crea a partir de una rama que ya existe en el servidor remoto. Por eso, antes de crear el PR, es imprescindible enviar (push) la nueva rama a GitHub.
Crear un Pull Request desde el IDE
Revise los dos lados de la comparación: base es la rama a la que se proponen los cambios, compare/head es la rama con su trabajo. Mire la lista de commits y el diff antes de crear el PR.
Ahora que su rama está en GitHub, ya puede crear el Pull Request.
Paso 1. Abra la pestaña Pull Requests. En la barra lateral izquierda del IDE, busque la pestaña Pull Requests. Ábrala y pulse el icono + (o el botón Create Pull Request).
Paso 2. Rellene los datos del PR. El IDE abrirá un formulario cómodo, y lo que le toca a usted es rellenarlo bien. Los campos principales:
- título - el IDE suele poner aquí el nombre de la rama o el texto del último commit; asegúrese de que el título sea breve, claro y refleje la esencia de los cambios;
- descripción - explique con detalle a sus compañeros qué ha hecho exactamente y para qué;
- revisores (Reviewers) - las personas a las que pide que revisen los cambios. Si su aprobación es obligatoria o no, lo fijan las reglas del repositorio;
- responsables (Assignees) - normalmente aquí se asigna usted mismo como autor y responsable de las correcciones tras la revisión.
Antes de pulsar Create Pull Request, revise una vez más base, head y el diff. Si el trabajo no está listo para revisión, puede crear un Draft PR cuando esa opción esté disponible. Tanto un PR normal como un draft ya son visibles para quienes tienen acceso al repositorio.
Revisión de código: comprobar y discutir
Una vez creado el PR, empieza la etapa más importante: la revisión de código (code review). Sus compañeros pueden abrir el PR, ver todos los cambios y dejar comentarios.
Todas las conversaciones se ven directamente en el IDE, en la pestaña Pull Requests. Si alguien comenta una línea de código, recibirá una notificación y podrá responder sin cambiar al navegador.
¿Qué hacer si le piden cambios? Muy sencillo: no hace falta crear un PR nuevo. Haga los cambios en la rama de origen de ese PR, cree un commit nuevo y envíelo. El Pull Request en GitHub se actualizará solo y añadirá los nuevos commits a la conversación existente.
Claude Code puede participar en la revisión de código: repasar los cambios del PR y dejar comentarios. Resulta útil como primer par de ojos, pero la decisión final y la responsabilidad sobre el código siguen siendo suyas y del equipo.
Cierre del trabajo: fusión y borrado de la rama
Cuando todas las observaciones están resueltas y el equipo aprueba los cambios (usted recibe el "approve"), el Pull Request se puede fusionar. Normalmente lo hace un desarrollador sénior, o usted mismo si tiene esos permisos en el repositorio.
Paso 1. Fusión. Revise las observaciones, las aprobaciones obligatorias y los estados de las comprobaciones. Si las reglas y sus permisos permiten la fusión, elija uno de los métodos disponibles (merge, squash o rebase) según las reglas del proyecto y confírmelo. Los cambios llegarán a la rama de destino del PR, en nuestro ejemplo main.
Paso 2. Borrado de la rama. Después de la fusión, la rama feature ya no hace falta, y conviene borrarla para no llenar el repositorio de ramas sueltas. GitHub mismo le propondrá hacerlo con el botón Delete branch.
Después de la fusión, cambie localmente a main, descargue las actualizaciones y compruebe que el resultado del PR está ahí. Luego puede borrar la rama local de la tarea, si no queda en ella trabajo que necesite. Si el IDE no le deja borrarla de la forma habitual, averigüe primero la causa, sobre todo después de un squash o un rebase.
Tres reglas de un buen commit
Un buen commit no es solo un mensaje correcto, sino también un contenido correcto. Para que el historial de cambios sea limpio y útil, siga tres reglas sencillas.
Regla 1 - escriba mensajes claros
Sus commits son mensajes para el equipo y para usted en el futuro. Un historial lleno de "fix" o "update" no sirve para nada. Uno de los formatos más extendidos es Conventional Commits. Propone esta estructura:
<tipo>: <descripción breve>
El tipo es una palabra corta que indica la categoría del cambio:
feat- funcionalidad nueva;fix- corrección de un error;docs- cambios en la documentación;style- ajustes de formato que no afectan a la lógica;refactor- cambios en el código que ni añaden funcionalidad ni corrigen errores;test- añadir o corregir tests;chore- tareas rutinarias (actualizar dependencias, configurar la compilación).
Ejemplos:
- Mal:
fixed bug - Bien:
fix: Correct user login validation - Mal:
readme - Bien:
docs: Update installation instructions
Pida a Claude Code que use el formato de mensajes adoptado en el repositorio. Conventional Commits no es obligatorio si el equipo ha elegido otra convención.
Regla 2 - un commit, un cambio lógico
No intente meter en un solo commit la corrección de un bug, una funcionalidad nueva y la refactorización de código antiguo. Un commit así es difícil de revisar y casi imposible de deshacer sin complicaciones. Cada commit debe resolver una tarea concreta.
- Mal: un único commit "Update user page" que añade un campo para el avatar, corrige la validación del nombre y cambia el color de los botones;
- Bien: tres commits separados:
feat: Add avatar upload to user profilefix: Correct username validation logicfeat: Update button colors on user page
Si en plena faena ha cambiado demasiadas cosas en un mismo archivo, el IDE le permite no hacer commit del archivo entero: en la ventana Commit puede desplegar el archivo y marcar solo los fragmentos (chunks) que corresponden a la tarea concreta.
Regla 3 - compruebe el resultado de los cambios
Antes de fusionar, ejecute las comprobaciones que correspondan al cambio y mire su resultado real. Para un ajuste en la documentación y para lógica nueva, el conjunto de comprobaciones será distinto.
Si el repositorio ya tiene comprobaciones automáticas configuradas, el PR muestra sus estados. Una marca verde significa que las comprobaciones concretas que se ejecutaron han pasado, no que se haya demostrado que no hay errores. Mire qué se ejecutó y qué quedó sin comprobar. Configurar la automatización es otro tema.
Cómo funciona todo esto junto con Claude Code
El PR es el punto donde Claude Code resulta especialmente útil. En qué fijarse:
- Claude puede crear un pull request a partir de su rama con el título y la descripción ya redactados - usted revisa el texto antes de que el PR se cree en GitHub;
- puede repasar los cambios del PR y dejar comentarios como primer par de ojos;
- ayuda a redactar los mensajes de commit según las reglas del proyecto;
- puede ayudar a leer los resultados de las comprobaciones ya configuradas y señalar lo que quedó sin comprobar.
Un PR existe para que el código se revise antes de llegar a main. Aunque la descripción y parte de la revisión las haya hecho Claude Code, la aprobación final y la responsabilidad de la fusión son de una persona. Lea qué se va a fusionar exactamente antes de pulsar Merge.
Artículo anterior: Ramas y fusión en Git · Artículo siguiente: Deshacer y recuperar cambios en Git
GO TO FULL VERSION