Qué es un pull request y cómo abrir el tuyo

Tu primer día en un equipo nuevo. Tienes el cambio commiteado en una rama local, funciona, y alguien te dice: «ábrenos un PR». Abres la terminal, escribes git pull-request y Git te responde que ese comando no existe. Ese hueco entre lo que sabes hacer tú solo y lo que hace un equipo es justo lo que voy a cerrar aquí, con la respuesta a qué es un pull request y los comandos exactos para abrir el tuyo.

¿Qué es un pull request (y por qué no lo encuentras en Git)?

Un pull request es una propuesta para fusionar los cambios de una rama en otra rama del repositorio, con un espacio de revisión y discusión antes de aceptarla. Traducido a tu situación: le dices al equipo «tengo este trabajo en mi rama, quiero meterlo en main, revisadlo».

La razón por la que git pull-request no existe es sencilla. Git no tiene el concepto de pull request. Git sabe hacer commits, ramas y merges, y poco más en lo que a esto respecta. Cuando fusionas dos ramas en tu máquina, eso es un git merge y punto: no hay conversación, ni revisión, ni botón de aprobar.

El pull request es una capa que ponen las plataformas por encima de ese merge. GitHub, GitLab o Bitbucket cogen una operación que Git ya sabía hacer y la envuelven en una interfaz: una página web donde se ve el diff, se comenta línea a línea, se aprueba o se rechaza, y solo cuando hay luz verde se ejecuta el merge de verdad. El PR es esa conversación de revisión que rodea al merge; la fusión técnica ya la sabía hacer Git desde siempre.

Un aviso rápido antes de seguir, porque confunde a mucha gente al empezar: git pull y «pull request» no tienen nada que ver. git pull es un comando de Git que se trae los cambios del remoto y los fusiona en tu rama local. El pull request va justo en la dirección contraria: propones que TU trabajo entre en el proyecto. Comparten dos palabras y nada más.

El recorrido completo: de tu rama al código del proyecto

El camino de un cambio, desde que lo escribes hasta que forma parte del proyecto, tiene cinco pasos. Primero creas una rama para tu trabajo. Segundo, la subes al repositorio remoto con git push. Tercero, abres el pull request en la plataforma. Cuarto, alguien lo revisa y te da comentarios o su aprobación. Y quinto, se hace el merge y tu código entra en la rama principal.

Fíjate en dónde ocurre cada paso. Los dos primeros pasan en Git, en tu terminal. Los tres últimos pasan en la plataforma, en el navegador. Esa frontera es la que más cuesta ver el primer día: la rama y el push son territorio de Git; el PR, la revisión y el botón de merge son territorio de GitHub.

Estos pasos intermedios cumplen una función concreta: permiten que varias personas toquen el mismo repositorio sin pisarse, y que nada entre en main sin que alguien lo haya mirado. El pull request es una pieza de algo más grande, el flujo de trabajo de un equipo con Git, y forma parte de las prácticas para trabajar en equipo con Git y GitHub.

Paso a paso: cómo abrir tu primer pull request

Vamos con los comandos reales. Partimos de que ya tienes el repositorio clonado y estás en main actualizado.

Lo primero es una rama propia para tu cambio. Nunca trabajes directamente sobre main: crea una rama con un nombre que describa lo que haces.

# Crea una rama nueva y cámbiate a ella en un solo paso
git switch -c fix/login-timeout

# ...editas tus archivos y compruebas que todo funciona...

# Preparas y confirmas el cambio
git add .
git commit -m "Corrige el timeout al iniciar sesión"

# Subes la rama al remoto y fijas su upstream con -u
git push -u origin fix/login-timeout

Dos notas sobre estos comandos. git switch -c crea la rama y te cambia a ella a la vez; es la forma moderna y recomendada de hacerlo (el equivalente antiguo, que todavía verás en tutoriales viejos, es git checkout -b). Y el -u de git push -u origin fix/login-timeout fija el upstream de la rama la primera vez: a partir de ahí te bastará con git push a secas para subir más commits.

Cuando el push termina, GitHub suele imprimir en la propia terminal un enlace directo para abrir el pull request de esa rama. Lo abres, revisas que la rama base sea la correcta (normalmente main), pones un título claro y una descripción de qué cambia y por qué, y le das a crear. Ya está: ese es tu primer PR.

Si prefieres no salir de la terminal, GitHub tiene su propia herramienta de línea de comandos, gh, que abre el PR sin tocar el navegador:

# Abre el PR contra main y rellena título y cuerpo desde tus commits
gh pr create --base main --fill

El flag --base indica la rama en la que quieres que se fusione tu código, y --fill rellena el título y el cuerpo a partir de tus commits para que no los escribas a mano. Al terminar te devuelve la URL del pull request creado.

Antes de seguir, practica el recorrido tú mismo. En este ejercicio interactivo abres un pull request paso a paso, sin miedo a romper nada:

Cargando ejercicio...

¿Qué pasa durante la revisión?

Una vez abierto el PR, la pelota pasa a quien revisa. La plataforma le muestra el diff completo: todo lo que has añadido, cambiado o borrado, archivo por archivo. Sobre ese diff puede dejar comentarios pegados a una línea concreta («esto peta si el array viene vacío») o un comentario general sobre el conjunto.

Al terminar, quien revisa deja el PR en uno de dos estados. Puede aprobarlo (approve), que es el visto bueno para fusionar. O puede pedir cambios (request changes), que bloquea el merge hasta que respondas a lo señalado. En muchos equipos hay reglas que exigen al menos una aprobación antes de poder mergear, así que un request changes significa que toca ponerse a trabajar otra vez.

Y aquí está la parte que a casi todo el mundo le sorprende la primera vez: para atender esos comentarios no abres un PR nuevo. Corriges en tu máquina, haces commit y empujas a la MISMA rama. El pull request se actualiza solo con los commits nuevos.

# Corriges lo que te han pedido, confirmas y vuelves a subir
git add src/auth.ts
git commit -m "Controla el caso de array vacío"
git push

Ese git push (ya sin -u, porque el upstream lo fijaste antes) añade el commit al PR abierto. Quien revisa verá el diff actualizado y podrá aprobar. Un pull request no es una foto fija de tu código en un instante: es un canal vivo que sigue a tu rama mientras esté abierto.

El merge: cómo entra tu código

Cuando el PR está aprobado, llega el paso final: el merge, que es lo que mete de verdad tus cambios en la rama principal. GitHub ofrece tres formas de hacerlo, y conviene saber en qué se diferencian aunque tu equipo ya tenga una elegida por ti.

El merge commit conserva todos tus commits tal cual y añade uno extra que une las dos ramas. Queda el historial completo de cómo trabajaste, con el coste de que el árbol de commits se llena de bifurcaciones. El squash and merge aplasta todos los commits de tu rama en uno solo antes de fusionar: el historial de main queda limpio, con una entrada por PR, a cambio de perder el detalle de tus commits intermedios. Y el rebase and merge reaplica tus commits uno a uno sobre la punta de la rama base, sin crear un commit de merge, dejando una línea recta.

No hay una opción «correcta» universal. Cada equipo decide según lo limpio que quiera su historial, y como colaborador casi siempre te encontrarás la decisión ya tomada. Lo único que sí es buena práctica en todos los casos: borrar la rama después de mergear, para no ir acumulando ramas muertas. La mayoría de plataformas te ofrecen un botón para hacerlo justo después del merge.

El mismo concepto con distinto nombre en cada plataforma

El nombre «pull request» es de GitHub. Otras plataformas hacen exactamente lo mismo con otra etiqueta, y esto genera confusión cuando cambias de trabajo o de proyecto.

Plataforma	Cómo lo llama	Nota
GitHub	Pull Request (PR)	El término que popularizó el nombre
GitLab	Merge Request (MR)	Mismo concepto; el nombre describe mejor lo que hace, que es pedir un merge
Bitbucket	Pull Request (PR)	Idéntico a GitHub en terminología
Gitea	Pull Request (PR)	Alternativa autoalojada; misma nomenclatura que GitHub

Si alguien de un equipo que usa GitLab te habla de un «MR», está hablando de un pull request. Cambia la palabra, no el concepto.

Abrir tu primer pull request es el paso que te convierte de alguien que usa Git para sí mismo en alguien que colabora en un equipo. Si quieres afianzar todo el recorrido, del primer commit hasta el merge, con ejercicios guiados como el de arriba, lo tienes en el curso Git de cero a profesional.

Un concepto nuevo cada semana

Suscribirme

Errores comunes al empezar con pull requests

El PR gigante de 40 archivos

El error más frecuente de quien empieza es acumular una semana de trabajo en una sola rama y abrir un PR que toca 40 archivos. Quien tiene que revisarlo se enfrenta a un muro: es imposible revisar bien cientos de líneas de golpe, así que o lo aprueba sin mirarlo de verdad o lo deja aparcado días. Un PR pequeño y enfocado se revisa en minutos y entra rápido. Divide tu trabajo en cambios que se puedan contar en una frase.

Confundir git pull con abrir un pull request

Ya lo vimos arriba, pero se repite tanto que merece su hueco aquí. Ejecutar git pull no abre ningún PR ni notifica a nadie: solo actualiza tu copia local con lo que hay en el remoto. Para proponer tu trabajo necesitas hacer git push de tu rama y después abrir el pull request en la plataforma.

Olvidar el push antes de abrir el PR

La plataforma solo ve las ramas que existen en el remoto. Si haces commit en local pero no ejecutas git push, tu rama no aparece en GitHub y no hay forma de abrir un PR con ella. El orden importa: primero el push, después el pull request.

Elegir la rama base equivocada

Al crear el PR eliges dos ramas: la tuya y la base donde quieres fusionar. Si pones como base una rama equivocada, o abres el PR contra el main de otra persona sin permiso, el diff mostrará cientos de cambios que no son tuyos y nadie sabrá qué revisar. Comprueba la rama base antes de crear el PR; si ya lo abriste mal, casi todas las plataformas dejan cambiarla sin cerrarlo.

Preguntas Frecuentes

¿Un pull request es lo mismo que git pull?

No, y es la confusión más habitual. git pull es un comando de Git que descarga los cambios del repositorio remoto y los fusiona en tu rama local. Un pull request es una propuesta, en una plataforma como GitHub, para que tu rama se fusione en el proyecto. Van en direcciones opuestas: git pull trae código hacia ti, el pull request empuja tu código hacia el proyecto.

¿Necesito GitHub para hacer un pull request?

Necesitas una plataforma de alojamiento, pero no tiene por qué ser GitHub. Git a secas no sabe qué es un pull request: solo hace merges. El concepto lo aportan las plataformas construidas encima de Git, como GitHub, GitLab, Bitbucket o Gitea. Con Git en solitario puedes fusionar ramas con git merge, pero no tendrás la revisión ni la conversación que da un PR.

¿Pull request y merge request son lo mismo?

Sí, es el mismo concepto con distinto nombre. GitHub y Bitbucket lo llaman pull request; GitLab lo llama merge request. La mecánica es idéntica: propones fusionar una rama en otra, hay revisión de por medio y al final alguien acepta. Si trabajas con GitLab, cada vez que leas «MR» tradúcelo mentalmente a «PR».

¿Puedo seguir haciendo commits después de abrir el PR?

Sí, y es justo así como se atienden los comentarios de la revisión. Mientras el pull request esté abierto, cualquier commit que empujes a esa misma rama con git push se añade automáticamente al PR. No abres uno nuevo por cada corrección: el mismo pull request se va actualizando hasta que se aprueba y se fusiona.

¿Quién hace el merge, yo o el revisor?

Depende del equipo. En algunos, quien abre el PR lo fusiona una vez tiene las aprobaciones necesarias; en otros, solo ciertas personas con permisos sobre main pueden pulsar el botón de merge. No hay una regla universal, así que cuando entres en un proyecto nuevo pregunta cuál es la convención antes de mergear nada tú mismo.