Pull request en Git: qué es y cómo crear un PR en GitHub

Un pull request (PR) es una propuesta para integrar los cambios de una rama en otra, publicada en una plataforma como GitHub. Subes la rama al servidor, abres el PR, el equipo ve el diff, comenta líneas, ejecuta las comprobaciones automáticas y solo después pulsa el botón de fusión. En GitLab el mismo mecanismo se llama merge request (MR). Si la pregunta es «¿qué es git pull request?», la respuesta corta es: el punto de control entre «he escrito el código» y «el código llega a main».

Qué significa pull request y de dónde viene el nombre

El nombre se formó por tradición. El autor de los cambios pide al responsable del repositorio que «extraiga» (pull) su rama, de ahí pull request. GitLab prefirió llamarlo por el resultado: merge request, solicitud de fusión. Bitbucket y Azure DevOps usan «pull request». En esencia es lo mismo: una rama de origen, una rama de destino, una descripción, la discusión, las comprobaciones y el botón de fusión.

Conviene tenerlo claro: el pull request no es parte de Git. En Git no existe un objeto «PR»; no se puede crear con un commit ni encontrar en la carpeta .git. Es una entidad de la plataforma: GitHub guarda la descripción, los comentarios y el estado de las comprobaciones, mientras que Git solo gestiona las ramas y los commits que forman parte del PR.

En la conversación de los desarrolladores, PR casi siempre significa pull request: «pásame el PR», «PR para revisión», «fusioné el PR». Para GitLab se dice MR.

Pull request y git pull: en qué se diferencian

Estos términos se confunden constantemente por lo parecido de las palabras. El comando git pull descarga los commits nuevos del repositorio remoto y los integra de inmediato en tu rama actual: es una operación local en la terminal. El pull request es una página web de GitHub con la propuesta de fusionar una rama en otra.

No existe un comando «git pull request» en Git. Hay una utilidad antigua, git request-pull, pero solo genera el texto de un correo con el resumen de cambios para enviarlo por lista de distribución; no tiene relación con los PR de GitHub.

Para qué sirven los pull requests

Mientras un proyecto lo lleva una sola persona, se puede hacer commit directamente en main. En cuanto hay dos o más personas, los push directos a la rama principal se convierten en fuente de builds rotos y de trabajo perdido. El pull request resuelve varios problemas a la vez:

• revisión de código: otra persona ve los cambios antes de que lleguen a main y detecta errores que el autor pasó por alto;
• comprobaciones automáticas: GitHub Actions u otro CI ejecuta pruebas y linters en cada PR, y un estado rojo impide fusionar código roto;
• historial de decisiones: un año después, en el PR se puede ver no solo qué se cambió, sino también por qué, con la discusión;
• contribuir a proyectos ajenos: en open source no tienes permiso de escritura, y el PR desde un fork es la única forma de proponer una corrección;
• protección de ramas: las reglas de protección de GitHub pueden prohibir el push directo a main y exigir un PR aprobado.

Cómo crear un pull request en GitHub desde una rama

Es el escenario habitual en un equipo donde todos tienen permiso de escritura en el repositorio. El trabajo se hace en una rama de funcionalidad y main cambia solo mediante PR.

Paso 1. Crea una rama a partir de main actualizado

git switch main
git pull
git switch -c feature/login-form

Conviene que el nombre de la rama sea descriptivo: feature/…, fix/…, número de la tarea. Así el revisor sabe de qué va sin abrir nada.

Paso 2. Haz los commits

git add src/login.js
git commit -m "Añadir formulario de inicio de sesión"

Un PR, una tarea. Un PR pequeño, de 100 a 300 líneas, se revisa rápido y con atención; con 3000 líneas el revisor aprueba casi sin mirar.

Paso 3. Envía la rama al servidor (git push para el pull request)

git push -u origin feature/login-form

La opción -u vincula la rama local con la remota, y a partir de ahí basta con git push. La respuesta de GitHub incluye el enlace para crear el PR:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/equipo/app/pull/new/feature/login-form

Paso 4. Abre el PR en la interfaz web

Entra en el enlace de la terminal o abre el repositorio en GitHub: tras un push reciente aparece un aviso con el botón «Compare & pull request». Otra vía es la pestaña «Pull requests» y el botón «New pull request».

1. Comprueba el par de ramas: base es el destino de la fusión (normalmente main) y compare es tu rama.
2. Escribe un título que diga qué se ha hecho, en forma breve e imperativa.
3. En la descripción explica el motivo, cómo comprobarlo y qué queda fuera del alcance. Si el repositorio tiene una plantilla de PR, los campos se rellenan solos.
4. A la derecha asigna revisores (Reviewers), responsables (Assignees) y etiquetas, si el equipo las usa.
5. Pulsa «Create pull request» o elige la opción de borrador, de la que hablamos más abajo.

Crear un PR desde la terminal: GitHub CLI

Si no quieres cambiar al navegador, existe la herramienta oficial gh. No es un comando de Git, sino un programa de GitHub, pero para los PR resulta muy cómoda:

gh pr create --base main --title "Añadir formulario de inicio de sesión" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

Si buscas «comandos git pull request», la respuesta honesta es esta: Git gestiona ramas, commits y push, mientras que el PR se crea en la plataforma: en el navegador, con gh o mediante la API.

Cómo hacer un pull request a un repositorio ajeno mediante un fork

En los proyectos abiertos no tienes permiso de escritura. Por eso primero creas un fork, una copia del repositorio en tu cuenta de GitHub; trabajas en ella y propones los cambios al original.

1. En la página del proyecto pulsa «Fork»: tendrás github.com/tu-usuario/proyecto.
2. Clona tu fork y añade el original como segundo remoto, normalmente llamado upstream.
3. Crea una rama, haz los commits y envía la rama a tu fork.
4. En GitHub abre el PR: repositorio base, el proyecto original; repositorio head, tu fork con tu rama.

git clone git@github.com:tu-usuario/proyecto.git
cd proyecto
git remote add upstream https://github.com/propietario/proyecto.git
git switch -c fix/typo-readme
git commit -am "Corregir errata en el README"
git push -u origin fix/typo-readme

Antes de empezar, mira el archivo CONTRIBUTING.md: normalmente describe las normas para los mensajes de commit, las pruebas y si hay que abrir primero un issue. Mantén el fork actualizado con git fetch upstream y git rebase upstream/main en tu rama, para que el PR no se quede atrás del original.

Merge request en GitLab: qué es y cómo crearlo

El merge request de la plataforma GitLab es el equivalente completo del pull request. Cambian los nombres y algunos detalles de la interfaz, pero el proceso es el mismo: rama, push, solicitud de fusión, revisión y fusión.

Puedes crear un MR de varias formas:

• con el enlace que GitLab muestra en la terminal tras hacer git push de una rama nueva;
• en la sección Merge requests del proyecto, con el botón «New merge request», eligiendo la rama de origen y la de destino;
• directamente en el push, con las opciones de push de GitLab, sin abrir el navegador.

git push -o merge_request.create -o merge_request.target=main origin feature/login-form

La terminología de GitLab es algo distinta: la aprobación se llama approve, el responsable de la fusión es el assignee, y en lugar de GitHub Actions se usa GitLab CI/CD con el archivo .gitlab-ci.yml. Los borradores también existen y se llaman Draft.

Revisar un pull request

El revisor abre la pestaña «Files changed» y ve el diff. Puede dejar un comentario en cualquier línea o proponer un cambio concreto (suggestion) que el autor aplica con un solo botón. Los comentarios se agrupan en una revisión y se envían juntos con uno de estos veredictos:

• Comment: observaciones sin decisión;
• Approve: los cambios están aprobados;
• Request changes: hay que corregir algo; no conviene fusionar todavía.

Una buena revisión se fija en la lógica, la legibilidad, las pruebas y los casos límite, en lugar de discutir gustos: el formato es mejor dejárselo al linter en el CI. El autor debe responder a cada comentario: lo corregí, lo hablamos o lo dejamos así, con una explicación.

Cómo probar un PR ajeno en local (git checkout pull request)

A veces hay que ejecutar el código en tu equipo. Si la rama está en el mismo repositorio, basta con git fetch y git switch. Para un PR desde un fork, GitHub ofrece referencias especiales pull/<número>/head:

git fetch origin pull/57/head:pr-57
git switch pr-57

En GitLab las referencias equivalentes se llaman merge-requests/<número>/head. O simplemente gh pr checkout 57, si tienes GitHub CLI.

Cómo actualizar un pull request tras las observaciones

El PR está vinculado a la rama, no a commits concretos. Basta con hacer commits nuevos en la misma rama y enviarlos: el PR se actualiza solo, sin crear una solicitud nueva.

git commit -am "Atender observaciones de la revisión"
git push

Git rebase en un pull request: traer el main actualizado

Mientras el PR espera revisión, main avanza. Si GitHub indica que la rama está desactualizada o hay conflictos, actualízala. La opción con rebase deja un historial lineal:

git fetch origin
git rebase origin/main
# resolver conflictos, git add, git rebase --continue
git push --force-with-lease

Tras un rebase cambian los hashes de los commits, así que un push normal se rechaza y hace falta uno forzado. Usa --force-with-lease: no sobrescribe la rama si en ella han aparecido commits ajenos. Si en la rama trabajáis varias personas, es más seguro incorporar main con git merge origin/main, sin reescribir el historial.

Cómo fusionar un pull request: merge, squash y rebase

Cuando la revisión está aprobada y las comprobaciones están en verde, el PR se puede fusionar. GitHub ofrece tres formas, y el administrador del repositorio puede dejar solo algunas.

Fusionar el pull request desde la interfaz equivale al git merge normal, solo que se ejecuta en el servidor. Tras la fusión, GitHub propone borrar la rama: acéptalo, ya no hace falta. En tu equipo, limpia lo local:

git switch main
git pull
git branch -d feature/login-form

También puedes fusionar a mano desde la terminal: integrar la rama en main en local y hacer push. GitHub detecta que los commits de la rama ya están en la base y marca el PR como fusionado. Pero así se saltan las comprobaciones y las reglas de protección, por eso en los equipos normalmente se fusiona con el botón.

Auto-merge y cola de fusión

Si las comprobaciones tardan mucho, puedes activar la fusión automática: el PR se fusionará solo cuando se cumplan todas las condiciones. En repositorios grandes se usa una cola de fusión (merge queue), que comprueba cada PR sobre los que ya están en la cola, para que main no se rompa por cambios incompatibles entre sí.

Borradores de pull request (Draft)

Un borrador es un PR que todavía no está listo para revisión. No se puede fusionar y los revisores no reciben la solicitud de revisión. Los borradores sirven para mostrar pronto la dirección del trabajo, ejecutar el CI o recoger opiniones sobre la arquitectura. En GitHub, al crear el PR elige la opción de borrador en el menú desplegable del botón de creación, o ejecuta gh pr create --draft. Cuando el trabajo esté terminado, pulsa «Ready for review». En GitLab, el borrador se marca con el prefijo Draft: en el título del MR.

Relación del pull request con los issues

Si en la descripción del PR escribes una palabra clave seguida del número de la tarea, GitHub cerrará el issue automáticamente al fusionar el PR en la rama por defecto:

Closes #42
Fixes #17
Resolves #8

Funcionan las palabras close, fix y resolve en sus distintas formas (closes, fixed, resolves). La simple mención #42 sin palabra clave crea un enlace, pero no cierra la tarea. En GitLab funcionan de forma parecida Closes #42 y frases similares.

¿Se puede borrar un pull request o un merge request?

Un participante normal no puede borrar un PR en GitHub: solo cerrarlo con el botón «Close pull request». El PR cerrado permanece en el historial y se puede reabrir. La rama, después de cerrarlo, se borra aparte. Eliminar del todo un PR solo es posible a través del soporte de GitHub, por ejemplo si en él se han publicado secretos.

En GitLab, el MR puede cerrarlo el autor o un miembro con permisos, y borrarlo, el propietario del proyecto o un administrador. Si en un PR ha quedado una contraseña o un token, cerrarlo no basta: revoca el secreto de inmediato, porque los commits ya estuvieron en el servidor.

Errores típicos con los pull requests

• PR desde main. Hiciste commits en tu main local y abriste el PR desde ahí. Los siguientes PR arrastrarán esos cambios antiguos. Trabaja siempre en una rama aparte.
• Rama base equivocada. El PR se abrió contra develop en lugar de main, o al revés. La base se cambia con el botón Edit junto al título del PR.
• Archivos de más en el diff. Builds, node_modules, .env. Añádelos a .gitignore y sácalos del índice con git rm --cached.
• PR enorme. Divide la tarea en varios PR encadenados.
• Push normal tras un rebase. Error rejected (non-fast-forward). Hace falta git push --force-with-lease, no --force.
• Conflictos resueltos a ciegas en el editor web. Actualiza main en local, resuelve el conflicto y comprueba las pruebas.

Pull request en git flow y otros procesos

El pull request encaja en cualquier proceso de equipo. En GitHub Flow es sencillo: rama desde main, PR, revisión, fusión y despliegue. En git flow, los PR se abren hacia develop desde las ramas de funcionalidad, y las ramas de release y hotfix también pasan por un PR hacia main. En el desarrollo basado en trunk, los PR son cortos y viven horas, no días. Sea cual sea el proceso, la regla es una: los cambios en ramas compartidas entran solo mediante pull request.

Resumen

El pull request es un mecanismo de la plataforma, no un comando de Git: una rama enviada al servidor más una página con la discusión, la revisión y las comprobaciones. En GitLab se llama merge request; en la conversación se dice PR o MR. Crea el PR desde una rama aparte, mantenlo pequeño, actualízalo con push a la misma rama y elige el método de fusión según el historial que quieras tener. Las ramas de funcionalidad, los forks y los pull requests se explican con práctica en el curso de Git.