Pull Request en GitHub: Qué es y cómo hacerlo paso a paso

Un Pull Request (PR) en GitHub permite proponer cambios en un repositorio para que otras personas puedan revisarlos, comentarlos y aprobarlos antes de incorporarlos a una rama principal. Es una de las herramientas fundamentales para trabajar en equipo y gestionar cambios de forma ordenada.

1. ¿Qué es un Pull Request?

Un Pull Request, también llamado PR, es una solicitud para incorporar los cambios realizados en una rama dentro de otra rama de un repositorio.

Por ejemplo, imaginemos un proyecto que tiene una rama principal llamada main y queremos desarrollar una nueva funcionalidad.

En lugar de modificar directamente main, podemos crear una nueva rama:

git switch -c nueva-funcionalidadLenguaje del código: JavaScript (javascript)

Realizamos los cambios, hacemos los commits y los enviamos a GitHub:

git push -u origin nueva-funcionalidad

Una vez que la rama está disponible en GitHub, podemos crear un Pull Request para solicitar que los cambios de nueva-funcionalidad sean incorporados a main.

El proceso sería:

Rama nueva
    ↓
Realizar cambios
    ↓
git commit
    ↓
git push
    ↓
Pull Request
    ↓
Revisión
    ↓
Aprobación
    ↓
Merge
    ↓
main

Por lo tanto, un Pull Request no es simplemente subir código a GitHub. Es el mecanismo que permite proponer, revisar y discutir cambios antes de incorporarlos a otra rama.

1.1. ¿Para qué sirve?

Entre otras cosas, un Pull Request permite:

• Mostrar qué cambios se realizaron.
• Comparar una rama con otra.
• Revisar el código.
• Dejar comentarios.
• Solicitar modificaciones.
• Aprobar los cambios.
• Ejecutar comprobaciones automáticas.
• Conversar sobre la implementación.
• Incorporar los cambios mediante un merge.

Esto hace que el proceso de desarrollo sea más controlado y colaborativo.

1.2. ¿Cuál es la diferencia entre Git push y Pull Request?

Es importante no confundir ambos conceptos.

git push envía commits desde el repositorio local hacia un repositorio remoto.

git push

Por ejemplo:

Computadora
    ↓
   push
    ↓
GitHub

En cambio, un Pull Request se utiliza en GitHub para proponer que los cambios de una rama sean incorporados en otra.

rama nueva
    ↓
Pull Request
    ↓
rama destino

Un flujo habitual sería:

git add
   ↓
git commit
   ↓
git push
   ↓
Pull Request
   ↓
Review
   ↓
Merge

Por eso, normalmente el Pull Request se crea después de hacer git push y publicar la rama en GitHub.

2. ¿En qué casos se utiliza?

Los Pull Requests son especialmente útiles cuando varias personas trabajan sobre un mismo proyecto, aunque también pueden utilizarse en proyectos individuales.

2.1. Trabajo en equipo

Es uno de los usos más habituales.

Por ejemplo:

• Ana trabaja en una nueva funcionalidad.
• Juan trabaja en otra parte del proyecto.
• Cada uno utiliza una rama diferente.
• Cuando Ana termina, crea un Pull Request.
• Juan revisa sus cambios.
• Después de aprobarlos, se incorporan a main.

De esta manera, no es necesario que cada desarrollador modifique directamente la rama principal.

2.2. Agregar una nueva funcionalidad

Por ejemplo, crear una nueva sección de una aplicación:

main
 │
 └── feature-login

Cuando la funcionalidad está terminada:

feature-login
      ↓
Pull Request
      ↓
main

2.3. Corregir un error

También podemos utilizar un Pull Request para solucionar un bug.

main
 │
 └── fix-menu-mobile

Después de realizar y probar la corrección, se crea un Pull Request hacia main.

2.4. Revisar código antes de incorporarlo

Un equipo puede establecer que ningún cambio llegue a main sin que otra persona lo revise.

Esto permite detectar:

• Errores.
• Código innecesario.
• Problemas de seguridad.
• Problemas de rendimiento.
• Incumplimiento de las convenciones del proyecto.

2.5. Contribuir a proyectos Open Source

Los Pull Requests son fundamentales en proyectos de código abierto.

Una persona puede hacer un fork del proyecto, realizar cambios en su propia copia y posteriormente crear un Pull Request para proponerlos al proyecto original.

3. ¿Cómo hacer un Pull Request paso a paso?

A continuación, veremos el proceso completo desde la creación de la rama hasta el momento de abrir el Pull Request.

3.1. Crear una nueva rama

Primero debemos crear una rama GitHub donde realizaremos nuestros cambios:

git switch -c nueva-funcionalidadLenguaje del código: JavaScript (javascript)

Por ejemplo:

git switch -c formulario-contactoLenguaje del código: JavaScript (javascript)

De esta manera, podemos trabajar en la nueva funcionalidad sin modificar directamente la rama main.

3.2. Realizar los cambios en el proyecto

Ahora podemos modificar, crear o eliminar los archivos necesarios.

Por ejemplo, podríamos agregar un archivo:

formulario-contacto.htmlLenguaje del código: CSS (css)

También podemos modificar archivos que ya existan en el proyecto.

3.3. Comprobar los cambios

Antes de crear el commit, es recomendable comprobar qué archivos fueron modificados:

git status

También podemos revisar exactamente qué cambios se realizaron:

git diff

Esto permite detectar posibles errores antes de enviar los cambios a GitHub.

3.4. Crear un commit

Cuando los cambios estén listos, los agregamos al área de preparación:

git add .

Después creamos el commit:

git commit -m "Agregar formulario de contacto"Lenguaje del código: JavaScript (javascript)

El commit guarda los cambios en el historial de Git.

3.5. Subir la rama a GitHub

Ahora debemos enviar nuestra rama al repositorio remoto:

git push -u origin formulario-contacto

Después de ejecutar este comando, la rama formulario-contacto estará disponible en GitHub.

Importante: hacer git push no crea por sí mismo el Pull Request. El comando solamente sube la rama y sus commits al repositorio remoto.

3.6. Entrar al repositorio en GitHub

Abrimos el repositorio en GitHub.

Después de subir una nueva rama, GitHub puede mostrar un aviso indicando que se ha realizado un nuevo push y ofreciendo la opción Compare & pull request.

También podemos crear el Pull Request manualmente desde:

Pull requests → New pull request

3.7. Seleccionar las ramas

En la pantalla de creación del Pull Request debemos seleccionar las dos ramas:

• base: rama que recibirá los cambios.
• compare: rama que contiene los cambios.

Por ejemplo:

base: main
compare: formulario-contactoLenguaje del código: HTTP (http)

En este caso estamos indicando que queremos incorporar los cambios de formulario-contacto dentro de main.

3.8. Revisar los cambios

GitHub mostrará una comparación entre ambas ramas.

Podremos revisar:

• Los archivos modificados.
• Las líneas agregadas.
• Las líneas eliminadas.
• Los commits incluidos.
• Las diferencias entre ambas ramas.

Es recomendable revisar esta información antes de crear definitivamente el Pull Request.

3.9. Escribir el título del Pull Request

El título debe explicar de forma breve qué se está haciendo.

Por ejemplo:

Agregar formulario de contacto

Es preferible utilizar un título descriptivo en lugar de uno demasiado genérico como:

Cambios

3.10. Agregar una descripción

En la descripción podemos explicar qué cambios se realizaron y cualquier información que pueda ayudar a los colaboradores a revisar el código.

Por ejemplo:

## Cambios realizados

- Se agregó un formulario de contacto.
- Se agregaron estilos para el formulario.
- Se incorporó validación de los campos obligatorios.

## Pruebas realizadas

- Se comprobó el envío del formulario.
- Se verificaron los campos obligatorios.Lenguaje del código: PHP (php)

Una buena descripción facilita que otras personas entiendan rápidamente el objetivo del Pull Request.

3.11. Crear el Pull Request

Una vez revisada toda la información, hacemos clic en:

Create pull request

GitHub creará el Pull Request y mostrará una página donde podremos consultar su estado, los cambios realizados y las revisiones.

3.12. Esperar la revisión

A partir de este momento, los colaboradores pueden revisar el código y dejar comentarios.

Pueden ocurrir diferentes situaciones:

Todo está correcto:

Pull Request
     ↓
Review
     ↓
Approve
     ↓
Merge

Se necesitan modificaciones:

Pull Request
     ↓
Request changes
     ↓
Modificar código
     ↓
Commit
     ↓
Push
     ↓
Nueva revisión

Si necesitamos hacer modificaciones, no tenemos que crear otro Pull Request. Simplemente realizamos los cambios en la misma rama y hacemos git push. Los nuevos commits aparecerán automáticamente en el Pull Request.

3.13. Hacer merge del Pull Request

Cuando los cambios hayan sido revisados y aprobados, un usuario con los permisos necesarios puede realizar el merge.

Por ejemplo:

formulario-contacto
        ↓
   Pull Request
        ↓
      Review
        ↓
      Approve
        ↓
       Merge
        ↓
       main

Después del merge, los cambios de formulario-contacto formarán parte de main.

3.14. Eliminar la rama

Una vez realizado el merge, si la rama ya no es necesaria, podemos eliminarla desde GitHub.

Por ejemplo:

formulario-contacto

puede eliminarse después de haber incorporado correctamente sus cambios a main.

Esto ayuda a mantener el repositorio limpio y organizado.

Ejemplo completo usando Pull Request

El proceso completo desde la terminal podría ser:

git switch -c formulario-contacto

# Realizar cambios en los archivos

git status
git add .
git commit -m "Agregar formulario de contacto"
git push -u origin formulario-contactoLenguaje del código: PHP (php)

Después continuamos desde GitHub:

GitHub
   ↓
Pull requests
   ↓
New pull request
   ↓
base: main
compare: formulario-contacto
   ↓
Revisar cambios
   ↓
Create pull request
   ↓
Review
   ↓
Approve
   ↓
MergeLenguaje del código: PHP (php)

De esta forma, el Pull Request actúa como un puente entre la rama donde desarrollamos una funcionalidad y la rama donde finalmente queremos incorporar esos cambios.

4. ¿Qué sucede después de crearlo?

Después de crear un Pull Request en GitHub, los cambios entran en una etapa de revisión antes de incorporarse a la rama de destino. Durante este proceso, los colaboradores pueden analizar el código, realizar comentarios, solicitar modificaciones y comprobar que todo funciona correctamente.

El flujo habitual es:

Pull Request creado
        ↓
Revisión de cambios
        ↓
¿Se necesitan modificaciones?
     ↙          ↘
   Sí            No
   ↓             ↓
Corregir       Aprobar
   ↓             ↓
Push          Merge
   ↓             ↓
Nueva revisión  Rama destino

Entonces, en este punto podemos realizar alguna de las siguientes acciones:

4.1. Revisar los cambios

Revisar un Pull Request significa analizar los cambios que otra persona propone incorporar al repositorio antes de aceptarlos. Durante la revisión se comprueba que el código funcione correctamente, que no introduzca errores y que cumpla con los requisitos y las buenas prácticas del proyecto.

En GitHub, la revisión permite consultar los archivos modificados, comparar las diferencias y dejar comentarios directamente sobre el código.

4.1.1. ¿Cómo revisar un Pull Request en GitHub?

1. Entrar al repositorio
   Accedemos al repositorio de GitHub donde se encuentra el Pull Request.
2. Abrir la sección Pull requests
   En el menú superior del repositorio hacemos clic en Pull requests.
3. Seleccionar el Pull Request
   Buscamos el Pull Request que queremos revisar y hacemos clic sobre su título.
4. Revisar la información general
   En la página del Pull Request podemos consultar su título, descripción, rama de origen, rama de destino, commits y estado de las comprobaciones automáticas.
5. Analizar los cambios
   En la pestaña Files changed podemos ver exactamente qué archivos fueron modificados. GitHub muestra las diferencias de forma visual:

- línea eliminada
+ línea agregada

Las líneas que comienzan con - corresponden a contenido eliminado y las que comienzan con + a contenido agregado.

6. Dejar comentarios
   Si encontramos algo que debería corregirse o mejorarse, podemos dejar un comentario sobre una línea concreta del código. Por ejemplo: Esta validación debería ejecutarse antes de enviar el formulario.
7. Comprobar las pruebas
   También conviene comprobar si las pruebas automáticas y otras verificaciones del repositorio han finalizado correctamente.
8. Finalizar la revisión
   Cuando terminamos de analizar los cambios, GitHub permite enviar la revisión indicando si:
   • Approve: los cambios están correctos.
   • Request changes: es necesario realizar modificaciones.
   • Comment: queremos dejar comentarios sin aprobar ni solicitar cambios.

4.1.2. ¿Qué se debería comprobar durante una revisión?

Una revisión no consiste solamente en comprobar si el código funciona. También conviene analizar aspectos como:

• ¿Los cambios cumplen el objetivo del Pull Request?
• ¿El código es correcto y fácil de entender?
• ¿Podría introducir algún error?
• ¿Se modificaron archivos que no eran necesarios?
• ¿Las pruebas funcionan correctamente?
• ¿Se respetan las convenciones del proyecto?
• ¿Existen problemas de seguridad o rendimiento?

Por ejemplo, si un Pull Request tiene como objetivo agregar un formulario de contacto, el revisor debería comprobar que el formulario funcione, que los campos estén correctamente validados y que los cambios realizados correspondan realmente con el objetivo descrito.

Una vez terminada la revisión, si todo está correcto, se puede aprobar el Pull Request y posteriormente realizar el merge. Si existen problemas, se solicitan cambios para que el autor pueda corregirlos antes de incorporarlos a la rama de destino.

4.2. Solicitar cambios

Solicitar cambios significa indicar que un Pull Request todavía no está listo para ser incorporado a la rama de destino porque es necesario corregir o modificar alguna parte del código.

Durante la revisión, si encontramos un error, una funcionalidad incompleta o algo que debería mejorarse, podemos utilizar la opción Request changes en GitHub. De esta forma, el autor del Pull Request recibe la indicación de que debe realizar modificaciones antes de que los cambios puedan aprobarse.

4.2.1. ¿Cuándo conviene solicitar cambios?

Por ejemplo, podemos solicitar cambios cuando:

• Existe un error en el código.
• Falta implementar una parte de la funcionalidad.
• Una prueba no funciona correctamente.
• El código no cumple con las convenciones del proyecto.
• Hay un problema de seguridad o rendimiento.
• Se modificaron archivos que no deberían haberse incluido.

La idea no es simplemente indicar que algo está mal, sino explicar qué debería modificarse y, cuando sea posible, por qué.

4.2.2. ¿Cómo solicitar cambios en un Pull Request?

1. Entramos al Pull Request que queremos revisar.
2. Revisamos los archivos modificados desde Files changed.
3. Analizamos el código y detectamos los puntos que necesitan corrección.
4. Podemos dejar comentarios sobre las líneas específicas que deben modificarse.
5. Una vez terminada la revisión, seleccionamos Review changes.
6. Elegimos Request changes.
7. Escribimos un comentario general explicando qué debe corregirse.
8. Enviamos la revisión.

Por ejemplo, podemos dejar un comentario como:

La validación del campo de email debería realizarse antes de enviar el formulario. Por favor, agrega esta validación y vuelve a ejecutar las pruebas.

Después de solicitar los cambios, el autor puede modificar el código en su rama:

git add .
git commit -m "Corregir validación del formulario"
git pushLenguaje del código: JavaScript (javascript)

El nuevo commit aparecerá automáticamente en el mismo Pull Request. El revisor podrá volver a analizar los cambios y comprobar si el problema fue solucionado.

El proceso sería:

Revisar Pull Request
        ↓
Detectar un problema
        ↓
Request changes
        ↓
Autor realiza modificaciones
        ↓
git commit
        ↓
git push
        ↓
Nueva revisión
        ↓
Approve
        ↓
Merge

Por lo tanto, solicitar cambios no rechaza definitivamente el Pull Request. Simplemente indica que todavía es necesario realizar algunas modificaciones antes de poder aprobarlo y hacer el merge.

4.3. Aprobar el Pull Request

Aprobar un Pull Request significa indicar que, después de revisar los cambios, consideramos que están correctos y cumplen con los requisitos del proyecto.

La aprobación permite que el Pull Request pueda continuar hacia el merge, siempre que no existan otras condiciones o revisiones pendientes.

Aprobar un Pull Request no significa necesariamente que los cambios se incorporen automáticamente a main. La incorporación se realiza posteriormente mediante el merge, si el usuario tiene los permisos necesarios.

4.3.1. ¿Cuándo conviene aprobar un Pull Request?

Antes de aprobarlo, es recomendable comprobar que:

• Los cambios cumplen con el objetivo del Pull Request.
• El código funciona correctamente.
• No existen errores evidentes.
• Las pruebas necesarias fueron realizadas correctamente.
• Los comentarios de la revisión fueron solucionados.
• No quedan cambios importantes pendientes.
• Las comprobaciones automáticas requeridas han finalizado correctamente.

4.3.2. ¿Cómo aprobar un Pull Request en GitHub?

1. Entramos al repositorio de GitHub.
2. Accedemos a Pull requests.
3. Seleccionamos el Pull Request que queremos revisar.
4. Revisamos la descripción y los commits.
5. Entramos en Files changed para analizar las modificaciones.
6. Comprobamos los comentarios y las pruebas automáticas.
7. Si todo está correcto, seleccionamos Review changes.
8. Elegimos la opción Approve.
9. Podemos agregar un comentario indicando que la revisión fue satisfactoria.
10. Finalmente, enviamos la revisión.

Por ejemplo, podemos escribir:

Los cambios fueron revisados y cumplen con los requisitos. Las pruebas se ejecutaron correctamente.

Una vez aprobado, el Pull Request puede continuar con el proceso de integración:

Pull Request
      ↓
Revisión
      ↓
Approve
      ↓
Merge
      ↓
main

4.3.3. ¿Qué ocurre después de aprobarlo?

Después de la aprobación, un usuario con los permisos correspondientes puede realizar el merge del Pull Request.

En algunos repositorios, el merge puede realizarse inmediatamente. En otros, pueden existir reglas que exijan, por ejemplo, varias aprobaciones, que todas las pruebas automáticas sean correctas o que no existan conflictos.

Por eso, aprobar un Pull Request significa que el revisor considera correctos los cambios; hacer merge es el paso posterior que incorpora esos cambios a la rama de destino.

4.4. Ejecutar comprobaciones automáticas

Las comprobaciones automáticas son procesos que GitHub puede ejecutar automáticamente cuando se crea o actualiza un Pull Request. Su objetivo es comprobar que los cambios cumplen determinadas condiciones antes de permitir o recomendar su incorporación a la rama de destino.

Estas comprobaciones pueden utilizarse, por ejemplo, para:

• Ejecutar pruebas automáticas.
• Detectar errores en el código.
• Comprobar el formato del código.
• Analizar posibles problemas de calidad.
• Verificar que el proyecto pueda compilarse correctamente.
• Comprobar determinadas reglas configuradas por el equipo.

Estas tareas suelen ejecutarse mediante GitHub Actions u otras herramientas de integración continua configuradas en el repositorio.

4.4.1. ¿Cómo funcionan las comprobaciones automáticas?

El proceso normalmente comienza cuando realizamos un push a la rama asociada al Pull Request.

Por ejemplo:

git add .
git commit -m "Agregar nueva funcionalidad"
git pushLenguaje del código: JavaScript (javascript)

Después del push, GitHub puede iniciar automáticamente las comprobaciones configuradas:

git push
    ↓
GitHub
    ↓
Pull Request
    ↓
Comprobaciones automáticas
    ↓
┌───────────────┐
│               │
✓ Correcto    ✕ Error
│               │
↓               ↓
Continuar     CorregirLenguaje del código: JavaScript (javascript)

4.4.2. ¿Cómo comprobar el resultado en GitHub?

Para consultar las comprobaciones de un Pull Request:

1. Entramos al repositorio en GitHub.
2. Abrimos Pull requests.
3. Seleccionamos el Pull Request.
4. Buscamos la sección de comprobaciones o el estado de los checks.
5. Revisamos si las tareas finalizaron correctamente o si alguna presentó un error.

GitHub puede mostrar diferentes estados. Por ejemplo:

• Passed / Success: la comprobación terminó correctamente.
• Failed: alguna comprobación encontró un problema.
• Pending / In progress: la comprobación todavía está ejecutándose.

Si todas las comprobaciones son correctas, podemos continuar con la revisión y aprobación del Pull Request.

4.4.3. ¿Qué hacer si una comprobación falla?

Si una comprobación automática falla, debemos revisar el motivo del error. GitHub normalmente permite acceder a los detalles de la ejecución para identificar qué tarea produjo el problema.

4.4.4. ¿Es obligatorio utilizar comprobaciones automáticas?

No. Un repositorio puede funcionar sin ellas. Sin embargo, son especialmente útiles en proyectos colaborativos porque permiten detectar determinados problemas automáticamente antes de incorporar los cambios.

Además, un repositorio puede configurarse para que un Pull Request no pueda hacerse merge mientras determinadas comprobaciones no hayan finalizado correctamente.

De esta manera, las comprobaciones automáticas funcionan como un filtro adicional dentro del flujo de trabajo:

Pull Request
      ↓
Comprobaciones automáticas
      ↓
Revisión del código
      ↓
Aprobación
      ↓
Merge

4.5. Hacer merge

Hacer merge de un Pull Request significa incorporar los cambios de una rama dentro de otra rama del repositorio. En el flujo habitual de GitHub, el merge se realiza después de que el Pull Request haya sido revisado y, cuando corresponde, aprobado.

Por ejemplo, si tenemos:

main
 │
 └── formulario-contacto

y la rama formulario-contacto contiene una nueva funcionalidad, hacer merge significa incorporar esos cambios a main:

formulario-contacto
        ↓
      Merge
        ↓
       main

De esta forma, los cambios que se desarrollaron en la rama pasan a formar parte de la rama de destino.

4.5.1. ¿Cuándo hacer merge?

Antes de hacer merge, es recomendable comprobar que:

• El Pull Request fue revisado.
• Los cambios cumplen con el objetivo planteado.
• Los comentarios importantes fueron solucionados.
• Las comprobaciones automáticas finalizaron correctamente.
• No existen conflictos que impidan la integración.
• Se cuenta con los permisos necesarios para realizar el merge.

En un proyecto colaborativo, normalmente el merge se realiza cuando el Pull Request ya fue aprobado por los revisores correspondientes.

4.5.2. ¿Cómo hacer merge de un Pull Request en GitHub?

1. Entramos al repositorio en GitHub.
2. Accedemos a Pull requests.
3. Seleccionamos el Pull Request que queremos integrar.
4. Revisamos que no haya problemas pendientes.
5. Comprobamos que las verificaciones automáticas hayan finalizado correctamente.
6. Si todo está listo, hacemos clic en Merge pull request o en la opción de merge disponible.
7. Revisamos la información que muestra GitHub.
8. Confirmamos la operación.

Una vez realizado el merge, los cambios pasan a formar parte de la rama de destino.

Por ejemplo:

Antes del merge:

main
 │
 ├── cambio A
 └── cambio B

feature-contacto
 │
 ├── cambio C
 └── cambio D

Después del merge:

main
 │
 ├── cambio A
 ├── cambio B
 ├── cambio C
 └── cambio D

La representación exacta del historial dependerá de la estrategia de merge utilizada.

4.5.3. ¿Qué opciones de merge existen?

GitHub puede ofrecer diferentes métodos para integrar un Pull Request:

1. Merge commit:
   • Incorpora los cambios creando un commit de merge.
2. Squash and merge:
   • Combina los commits del Pull Request en un único commit antes de incorporarlos a la rama de destino.
3. Rebase and merge:
   • Reorganiza los commits del Pull Request sobre la rama de destino y los incorpora sin crear un commit de merge tradicional.

La opción disponible dependerá de la configuración del repositorio.

4.5.4. ¿Qué hacer después del merge?

Una vez incorporados los cambios, si la rama ya no se necesita, podemos eliminarla desde GitHub.

Por ejemplo:

Pull Request
     ↓
Review
     ↓
Approve
     ↓
Merge
     ↓
Eliminar rama

Es importante entender que hacer merge no es lo mismo que crear un Pull Request. El Pull Request sirve para proponer y revisar los cambios, mientras que el merge es la acción que finalmente integra esos cambios en la rama de destino.

4.6. Cerrar el Pull Request

Cerrar un Pull Request significa finalizar la solicitud sin incorporar sus cambios a la rama de destino. Al cerrarlo, GitHub marca el Pull Request como terminado y deja de estar pendiente de revisión o merge.

Por ejemplo, podemos cerrar un Pull Request cuando:

• Los cambios ya no son necesarios.
• Se decidió utilizar otra solución.
• El desarrollo fue cancelado.
• El Pull Request contiene cambios que no queremos incorporar.
• Se creó otro Pull Request que reemplaza al anterior.

Es importante diferenciar cerrar de hacer merge. Cuando hacemos merge, los cambios se incorporan a la rama de destino. Cuando simplemente cerramos el Pull Request, los cambios no se incorporan mediante ese Pull Request.

4.6.1. ¿Cómo cerrar un Pull Request en GitHub?

1. Entramos al repositorio en GitHub.
2. Accedemos a Pull requests.
3. Seleccionamos el Pull Request que queremos cerrar.
4. Revisamos que realmente no sea necesario incorporarlo.
5. En la parte inferior de la conversación seleccionamos Close pull request.

Una vez cerrado, GitHub mostrará el Pull Request como Closed.

El flujo sería:

Pull Request abierto
        ↓
Decidir no incorporarlo
        ↓
Close pull request
        ↓
Pull Request cerrado

4.6.2. ¿Se puede volver a abrir un Pull Request cerrado?

Sí. Si posteriormente decidimos continuar con los cambios, un Pull Request cerrado puede volver a abrirse en determinadas circunstancias utilizando la opción Reopen pull request.

Por ejemplo:

Pull Request
     ↓
   Closed
     ↓
¿Se necesitan los cambios?
     ↓
   Reopen
     ↓
   Open

Esto permite continuar con el proceso de revisión sin tener que crear necesariamente un Pull Request completamente nuevo.

4.6.3. ¿Cerrar un Pull Request elimina la rama?

No necesariamente. Cerrar un Pull Request y eliminar la rama son acciones diferentes.

Por ejemplo:

Pull Request → Closed
       │
       └── Rama todavía existe

La rama puede permanecer disponible para continuar trabajando en ella o eliminarse posteriormente si ya no es necesaria.

Por lo tanto, cerrar un Pull Request simplemente finaliza esa solicitud de integración. Los cambios de la rama no pasan automáticamente a main, y la rama tampoco se elimina automáticamente por el hecho de cerrar el Pull Request.

5. Eliminar la rama después del Pull Request

Una vez que un Pull Request ha sido integrado mediante un merge, la rama utilizada para desarrollar esos cambios normalmente deja de ser necesaria. En ese caso, podemos eliminarla para mantener el repositorio organizado.

Por ejemplo, si trabajamos en:

feature-login

y finalmente hacemos:

feature-login
      ↓
Pull Request
      ↓
Merge
      ↓
main

una vez que los cambios ya están en main, podemos eliminar feature-login.

5.1. ¿Por qué eliminar la rama después del Pull Request?

Eliminar las ramas que ya no se utilizan tiene varias ventajas:

• Mantiene el repositorio ordenado.
• Evita acumular ramas antiguas.
• Facilita encontrar las ramas que realmente están activas.
• Reduce la posibilidad de trabajar accidentalmente sobre una rama que ya no corresponde.
• Permite identificar mejor las funcionalidades que todavía están en desarrollo.

Por ejemplo, un repositorio podría terminar teniendo muchas ramas:

main
feature-login
feature-contacto
fix-menu
fix-header
feature-pagos
feature-perfil

Si algunas de ellas ya fueron integradas y no se eliminan, la lista puede crecer innecesariamente.

5.2. ¿Es obligatorio eliminar la rama?

No. Eliminar una rama después del Pull Request es una buena práctica, pero no es obligatorio.

Podemos conservarla si:

• Todavía necesitamos trabajar en ella.
• Queremos continuar desarrollando esa funcionalidad.
• El equipo tiene una política específica para conservar ramas.
• Necesitamos consultar o continuar con ese trabajo posteriormente.

Si el Pull Request fue integrado y la rama ya no tiene ninguna utilidad, normalmente sí conviene eliminarla.

5.3. ¿Cómo eliminar la rama desde GitHub?

Después de hacer merge del Pull Request, GitHub suele mostrar una opción para eliminar la rama.

Por ejemplo:

1. Abrimos el Pull Request.
2. Comprobamos que se haya realizado correctamente el merge.
3. Buscamos la opción Delete branch.
4. Hacemos clic sobre ella.

La rama remota será eliminada de GitHub.

Pull Request
      ↓
Merge
      ↓
Cambios incorporados en main
      ↓
Delete branch
      ↓
Rama eliminada

Importante: eliminar la rama después del merge no elimina los cambios que ya fueron incorporados a main. Los commits que forman parte del historial de main continúan allí.

5.4. ¿Cómo eliminar la rama local?

Si también tenemos esa rama en nuestra computadora, podemos eliminarla desde Git:

git branch -d feature-login

La opción -d permite eliminar la rama local cuando Git considera que sus cambios ya fueron integrados.

Por ejemplo:

git switch main
git branch -d feature-loginLenguaje del código: JavaScript (javascript)

Primero cambiamos a main porque no podemos eliminar la rama en la que estamos trabajando actualmente.

Si además queremos actualizar las referencias de las ramas remotas después de haber eliminado la rama en GitHub, podemos utilizar:

git fetch --prune

Esto permite limpiar referencias locales de ramas remotas que ya fueron eliminadas.

5.5. ¿Qué pasa si elimino la rama por error?

Si la rama ya fue integrada mediante merge, sus cambios continúan formando parte del historial de main. Por lo tanto, eliminar la rama no significa perder automáticamente el trabajo realizado.

En muchos casos, además, GitHub permite recuperar una rama eliminada desde el Pull Request correspondiente.

En resumen, un flujo habitual después de terminar un Pull Request es:

Crear rama
    ↓
Realizar cambios
    ↓
Pull Request
    ↓
Revisión
    ↓
Aprobación
    ↓
Merge
    ↓
Eliminar rama

De esta manera, las ramas se utilizan para desarrollar funcionalidades o correcciones concretas y, una vez que su trabajo ha sido integrado y ya no son necesarias, pueden eliminarse para mantener el repositorio limpio y organizado.

6. Actualizar un Pull Request

Actualizar un Pull Request significa agregar nuevos cambios al mismo Pull Request después de haberlo creado. Esto ocurre normalmente cuando encontramos un error, un revisor solicita modificaciones o necesitamos seguir trabajando en la funcionalidad propuesta.

No es necesario crear un nuevo Pull Request cada vez que hacemos una modificación. Mientras los nuevos cambios se realicen sobre la misma rama asociada al Pull Request, al hacer git push GitHub actualizará automáticamente el Pull Request existente.

Por ejemplo:

Rama: nueva-funcionalidad
          ↓
    Pull Request
          ↓
  Revisión del código
          ↓
  Solicitan cambios
          ↓
Modificar archivos
          ↓
   git commit
          ↓
    git push
          ↓
Pull Request actualizado

6.1. ¿Cómo actualizar un Pull Request?

Supongamos que ya tenemos un Pull Request creado desde:

nueva-funcionalidad → main

y el revisor nos solicita modificar alguna parte del código.

6.1.1. Cambiar los archivos

Realizamos las modificaciones necesarias en nuestro proyecto local.

Por ejemplo, podemos corregir una función o agregar una validación que faltaba.

6.1.2. Comprobar los cambios

Podemos revisar el estado del repositorio:

git status

Y consultar las diferencias:

git diff

Esto permite comprobar exactamente qué vamos a incorporar al Pull Request.

6.1.3. Crear un nuevo commit

Después de realizar las modificaciones:

git add .

Creamos un nuevo commit:

git commit -m "Corregir validación del formulario"Lenguaje del código: JavaScript (javascript)

6.1.4. Hacer push

Ahora enviamos el nuevo commit a GitHub:

git push

Como estamos trabajando sobre la misma rama asociada al Pull Request, GitHub incorporará automáticamente el nuevo commit al PR.

Por ejemplo:

Antes:

Pull Request #15
 ├── Commit 1
 └── Commit 2

Después de git push:

Pull Request #15
 ├── Commit 1
 ├── Commit 2
 └── Commit 3Lenguaje del código: CSS (css)

No tenemos que crear otro Pull Request.

6.2. ¿Qué ocurre en GitHub después del push?

GitHub actualizará automáticamente el Pull Request y mostrará los nuevos cambios.

El revisor podrá comprobar nuevamente el código:

Pull Request
     ↓
Nuevos cambios
     ↓
Nueva revisión
     ↓
¿Está correcto?
   ↙       ↘
 No         Sí
 ↓           ↓
Cambiar    Aprobar
 ↓           ↓
Push       Merge

Si el revisor vuelve a encontrar algún problema, podemos repetir el mismo proceso.

6.3. ¿Cuándo es necesario actualizar un Pull Request?

Es habitual actualizarlo cuando:

• Un revisor solicita cambios.
• Se detecta un error durante las pruebas.
• Faltaba implementar una parte de la funcionalidad.
• Es necesario corregir un conflicto.
• Se realizan mejoras adicionales relacionadas con el objetivo del PR.
• Las comprobaciones automáticas detectan un problema.

7. ¿Quién puede crearlo?

Un Pull Request puede ser creado por cualquier usuario que tenga acceso a una rama desde la que pueda proponer cambios hacia otra rama del repositorio. Sin embargo, los permisos necesarios dependen de si trabajas en un repositorio propio, en uno donde colaboras o en un proyecto en el que no tienes permisos de escritura.

7.1. En un repositorio propio

Si el repositorio es tuyo, puedes crear Pull Requests entre las diferentes ramas del proyecto.

Por ejemplo, puedes tener una rama principal llamada main y crear una rama para desarrollar una nueva funcionalidad:

git switch -c nueva-funcionalidadLenguaje del código: JavaScript (javascript)

Después de realizar los cambios, puedes subir la rama a GitHub:

git add .
git commit -m "Agregar nueva funcionalidad"
git push -u origin nueva-funcionalidadLenguaje del código: JavaScript (javascript)

Una vez subida la rama, puedes crear un Pull Request desde GitHub para proponer la integración de nueva-funcionalidad en main.

El flujo sería:

main
  ↓
nueva-funcionalidad
  ↓
hacer cambios
  ↓
git push
  ↓
Pull Request
  ↓
revisión
  ↓
merge
  ↓
main

7.2. En un repositorio donde eres colaborador

También puedes crear Pull Requests en un repositorio de otra persona u organización si tienes los permisos necesarios para trabajar con el repositorio.

Por ejemplo, si formas parte de un equipo de desarrollo, puedes crear una rama, realizar cambios y subirla al repositorio:

git switch -c corregir-login
git add .
git commit -m "Corregir validación del login"
git push -u origin corregir-loginLenguaje del código: JavaScript (javascript)

Después puedes utilizar esa rama para crear el Pull Request hacia main u otra rama de destino.

Los responsables del proyecto pueden configurar además reglas que determinen quién puede aprobar, hacer merge o modificar determinadas ramas.

7.3. ¿Se puede crear un Pull Request sin tener permisos de escritura?

Sí. Esta es una situación muy habitual en proyectos de código abierto.

Cuando un usuario no tiene permisos para crear ramas directamente en el repositorio original, puede realizar un fork del proyecto. El fork crea una copia del repositorio en su propia cuenta de GitHub.

El flujo sería:

Repositorio original
        ↓
      Fork
        ↓
Repositorio propio
        ↓
crear rama
        ↓
hacer cambios
        ↓
git push
        ↓
Pull Request
        ↓
Repositorio original

De esta manera, el usuario puede desarrollar sus cambios en su propio repositorio y posteriormente proponerlos al proyecto original mediante un Pull Request.

7.4. ¿Quién decide si el Pull Request se acepta?

Crear un Pull Request no significa que los cambios vayan a incorporarse automáticamente al proyecto.

Normalmente, los colaboradores o responsables del repositorio revisan los cambios y pueden:

• Aprobar el Pull Request.
• Solicitar modificaciones.
• Comentar determinados cambios.
• Esperar a que pasen las comprobaciones automáticas.
• Hacer merge del Pull Request.
• Cerrar el Pull Request sin hacer merge.

Por ejemplo, un desarrollador puede crear un Pull Request para agregar una nueva función, pero el responsable del proyecto puede solicitar algunos cambios antes de aprobarlo.

7.5. Permisos para crear y hacer merge no son necesariamente los mismos

Es importante distinguir entre crear un Pull Request y hacer merge.

Un usuario puede tener permiso para proponer cambios mediante un Pull Request, pero no necesariamente tener permiso para integrarlos directamente en main.

Esto permite que los proyectos utilicen un sistema de revisión:

Desarrollador
     ↓
Crea Pull Request
     ↓
Revisión
     ↓
Aprobación
     ↓
Merge realizado por un usuario autorizado

Esta separación es especialmente útil en equipos de desarrollo, porque evita que cualquier colaborador pueda incorporar cambios directamente a las ramas principales.

7.6. En resumen

Cualquier usuario puede proponer cambios mediante un Pull Request siempre que tenga una rama desde la que pueda realizar la propuesta. En un repositorio propio o donde tenga permisos de escritura, puede crear la rama directamente. Si no tiene permisos sobre el repositorio original, puede utilizar un fork y crear el Pull Request desde su propia copia.

Por otro lado, crear un Pull Request y hacer merge son acciones diferentes: el primero propone los cambios para su revisión, mientras que el segundo incorpora esos cambios a la rama de destino.

8. ¿Cómo revertirlo?

Revertir un Pull Request significa deshacer los cambios que fueron incorporados a una rama mediante ese Pull Request.

Es útil cuando un cambio ya fue integrado, pero posteriormente se detecta un error, un comportamiento inesperado o algún problema que requiere volver al estado anterior.

Es importante diferenciar entre cerrar un Pull Request y revertirlo. Cerrar un Pull Request evita que se haga merge, mientras que revertir un Pull Request que ya fue integrado crea nuevos cambios que deshacen lo que se había incorporado.

8.1. ¿Cuándo conviene revertir un Pull Request?

Puede ser necesario revertir un Pull Request cuando, después de hacer merge, se descubre que los cambios provocaron algún problema.

Por ejemplo:

Rama main
   ↓
Pull Request
   ↓
Merge
   ↓
Se detecta un error
   ↓
Revertir los cambios
   ↓
main vuelve a un estado anterior

Algunos casos habituales son:

• Una nueva funcionalidad provoca errores.
• Un cambio rompe otra parte del proyecto.
• Se incorporó código incorrecto.
• Una modificación genera problemas en producción.
• Se necesita retirar temporalmente una funcionalidad.
• El Pull Request se integró por error.

8.2. ¿Cómo revertir un Pull Request desde GitHub?

Cuando un Pull Request ya fue integrado mediante GitHub, en determinados casos GitHub ofrece la opción Revert para crear automáticamente un nuevo Pull Request que deshace los cambios del Pull Request original.

El procedimiento general es:

1. Entra en el repositorio de GitHub.
2. Accede a Pull requests.
3. Busca el Pull Request que quieres revertir.
4. Abre el Pull Request que ya fue integrado.
5. Busca la opción Revert.
6. GitHub preparará los cambios necesarios para deshacer ese Pull Request.
7. Se creará un nuevo Pull Request con esos cambios.
8. Revisa los cambios.
9. Si todo es correcto, realiza el merge del nuevo Pull Request.

El flujo sería:

Pull Request original
        ↓
      Merge
        ↓
Se detecta un problema
        ↓
      Revert
        ↓
Nuevo Pull Request
        ↓
Revisión
        ↓
      Merge
        ↓
Cambios originales deshechos

8.3. ¿Qué hace realmente Revert?

La opción Revert no elimina el Pull Request original ni borra su historial.

En lugar de modificar el pasado, Git crea nuevos cambios que tienen el efecto contrario a los cambios que se habían incorporado.

Por ejemplo, si el Pull Request original agregó:

archivo.html
archivo.css
archivo.js
Lenguaje del código: CSS (css)

y posteriormente se revierte, Git crea nuevos cambios para deshacer esas modificaciones.

Por eso, el historial conserva tanto el cambio original como su posterior reversión.

Commit A
   ↓
Commit B  ← Cambios del Pull Request
   ↓
Commit C  ← Revert

Esto permite mantener un historial claro de lo que ocurrió en el proyecto.

8.4. ¿Se puede revertir un Pull Request desde Git?

Sí. También puedes revertir los cambios desde el repositorio local utilizando Git.

Una forma habitual es identificar el commit que quieres revertir:

git log --oneline

Después puedes utilizar:

git revert ID_DEL_COMMIT

Por ejemplo:

git revert a1b2c3d

Git creará un nuevo commit que deshace los cambios realizados por ese commit.

Después puedes subir el nuevo commit a GitHub:

git push

Si estás trabajando mediante una rama específica para realizar la reversión, el proceso puede ser:

git switch -c revert-cambios
git revert a1b2c3d
git push -u origin revert-cambios
Lenguaje del código: JavaScript (javascript)

Luego puedes crear un nuevo Pull Request para revisar y aplicar la reversión.

8.5. ¿Qué ocurre si el Pull Request contiene varios commits?

Un Pull Request puede contener varios commits. En esos casos, utilizar la opción Revert de GitHub puede ser más sencillo porque permite revertir el conjunto de cambios asociado al Pull Request integrado.

Si realizas la operación manualmente con Git, debes tener cuidado con el orden y las dependencias entre los commits.

Por ejemplo:

Commit 1 → nueva función
Commit 2 → modificación de la función
Commit 3 → corrección

Revertir solamente uno de ellos podría dejar el proyecto en un estado inesperado si los commits dependen entre sí.

Por eso, cuando el objetivo es deshacer un Pull Request completo, conviene analizar primero todos los cambios que introdujo.

8.6. ¿Revertir un Pull Request elimina los cambios del historial?

No. Revertir no elimina el historial.

El cambio original continúa apareciendo en los commits del repositorio y se agrega un nuevo commit que lo deshace.

Esto es diferente de utilizar operaciones como git reset para modificar el historial local.

Por ejemplo:

Antes:

A → B → C
        ↑
    Pull Request


Después del revert:

A → B → C → D
            ↑
          Revert

El commit C sigue existiendo. El commit D simplemente deshace sus efectos.

8.7. ¿Se puede volver a aplicar un Pull Request que fue revertido?

Sí. Si posteriormente quieres recuperar los cambios que habías revertido, puedes volver a aplicar esos cambios.

Esto puede hacerse revirtiendo el commit de reversión o mediante un nuevo conjunto de cambios, dependiendo de la situación.

Por ejemplo:

Pull Request
     ↓
   Merge
     ↓
   Revert
     ↓
Se corrige el problema
     ↓
Volver a aplicar cambios

Sin embargo, antes de volver a incorporarlos conviene corregir el problema que provocó la reversión.

8.8. Revertir un Pull Request no es lo mismo que eliminarlo

Es importante distinguir estos conceptos:

Acción	¿Qué sucede?
Cerrar Pull Request	El Pull Request no se integra
Eliminar una rama	Se elimina la rama, pero no necesariamente sus commits integrados
Revertir Pull Request	Se crean nuevos cambios que deshacen los cambios integrados
git reset	Puede modificar el historial de commits
git revert	Crea un nuevo commit que deshace cambios anteriores

Por lo tanto, si un Pull Request ya fue integrado mediante merge y quieres deshacer sus efectos sin eliminar el historial, revert suele ser la opción adecuada.

8.9. Ejemplo práctico

Imagina que desarrollas una nueva sección para una página web en la rama:

nueva-seccion

Realizas los cambios y creas un Pull Request hacia main.

Después de revisarlo:

nueva-seccion → Pull Request → main

El Pull Request se aprueba y se hace merge.

Sin embargo, posteriormente se descubre que la nueva sección provoca un error.

En lugar de eliminar los commits del historial, puedes revertir el Pull Request:

Pull Request
     ↓
    Merge
     ↓
   Error
     ↓
   Revert
     ↓
Nuevo Pull Request
     ↓
    Merge
Lenguaje del código: JavaScript (javascript)

El resultado es que los efectos de la nueva sección quedan deshechos, pero el historial conserva información sobre el cambio original y sobre su reversión.

8.10. En resumen

Revertir un Pull Request significa deshacer los cambios que fueron incorporados al repositorio mediante ese Pull Request. No elimina el Pull Request original ni borra los commits del historial. En GitHub, cuando la opción está disponible, puedes utilizar Revert para generar un nuevo Pull Request que deshaga esos cambios.

La idea principal es:

Pull Request → Merge → Problema → Revert → Nuevo Pull Request → Merge

De esta forma, puedes retirar cambios problemáticos manteniendo un historial de Git claro y trazable.