# Ramas y pull requests explicados sin jerga

> Una rama es una línea de trabajo aparte y un pull request, la propuesta para integrarla. Cómo revisar un cambio hecho por IA antes de que llegue a producción.

*Tags: ia, git, revision, ux-para-ia*

---


> [!info] Definición Rápida
> **Una rama** es una línea de trabajo separada dentro de un proyecto. **Un pull request** es la propuesta para integrar esa rama en la versión principal, con espacio para comentar y revisar antes de aceptar. Juntos permiten probar cambios de una IA sin arriesgar lo que ya funciona.


Si no tienes claro qué es un commit o un diff, empieza por [[git-para-disenadores|Git para diseñadores]]. Aquí nos centramos en lo que viene después: cómo usar ramas y pull requests para revisar lo que hace una IA.

## ¿Por qué conviene que la IA trabaje en una rama?

Una IA puede tocar muchos archivos en un solo paso. Si lo hace directamente sobre la versión principal, cualquier error llega a todos, y deshacerlo exige adivinar qué se movió. En una rama, el cambio queda aislado: si sale mal, se descarta la rama y la versión principal sigue como estaba.

La guía oficial de GitHub lo plantea así: al crear una rama se crea un espacio para trabajar sin afectar la rama predeterminada, y conviene darle un nombre corto y descriptivo para que los colaboradores vean de un vistazo qué se está haciendo. Sus ejemplos son `increase-test-timeout` y `add-code-of-conduct` ([GitHub Docs, GitHub flow](https://docs.github.com/en/get-started/using-github/github-flow)). En español sirve igual: `corregir-formulario-contacto`.

También permite trabajar en paralelo. Si el rediseño del menú tarda una semana y una corrección del formulario tarda una hora, cada tarea vive en su rama y la corrección no espera al rediseño.

## ¿Qué es un pull request y qué contiene?

Es la solicitud formal para integrar los cambios de una rama en otra, normalmente la principal. GitHub lo define como una propuesta para integrar cambios en un proyecto, y lo organiza en pestañas ([GitHub Docs, About pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)):

| Pestaña | Qué muestra |
|---|---|
| Conversation | La descripción, la línea de tiempo, los comentarios y las revisiones |
| Commits | Cómo cambió la rama con el tiempo |
| Files changed | El diff que usan quienes revisan para entender el cambio |
| Checks | Resultados de pruebas y compilaciones automáticas |

Quien revisa puede comentar el conjunto o una línea concreta, y el autor sube más cambios para responder. Cuando el cambio está listo, se integra y la rama se borra.

Las revisiones son de tres tipos: comentar sin aprobar ni rechazar, aprobar (los cambios están listos para integrarse) o pedir cambios antes de integrar. La revisión es opcional salvo que un administrador del repositorio exija aprobaciones antes de integrar ([GitHub Docs, About pull request reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)).

GitHub también ofrece pull requests en borrador. Un borrador no se puede integrar, y a los responsables de código no se les pide revisión automáticamente hasta que se marca como listo. Es útil cuando la IA aún trabaja o cuando quieres enseñar un avance sin riesgo de que se integre por error.

## ¿Cómo se revisa un pull request hecho por una IA?

El flujo típico es este:

1. Creas una rama para la tarea.
2. La IA hace el cambio en esa rama y se guardan commits con descripciones claras.
3. Abres un pull request con una descripción de tres líneas: qué cambió, por qué y cómo se prueba.
4. Revisas el diff completo en la pestaña de archivos cambiados, no solo la pantalla. Buscas archivos inesperados, datos nuevos y dependencias agregadas.
5. Si algo sobra, pides a la IA que lo quite y actualizas el pull request.
6. Integras cuando los criterios de la tarea se cumplen y borras la rama.

Una práctica sencilla: un pull request por tarea. Si un cambio mezcla tres asuntos, es difícil revisarlo y, si uno falla, bloquea a los otros dos. Cuando una tarea dura más de un día, divídela en pull requests pequeños, cada uno con su propia revisión.

## ¿Qué miro en el diff de la IA?

Con la lista de criterios de la tarea a la vista, comprueba cuatro cosas:

- **Alcance.** ¿Los archivos tocados corresponden a lo que pediste? Un archivo de configuración o de validación que nadie mencionó merece una pregunta.
- **Lo que se borró.** Las líneas en rojo importan tanto como las verdes. Una comprobación eliminada puede hacer que algo «funcione» sin estar bien.
- **Dependencias y datos nuevos.** Paquetes agregados, claves, URLs o textos copiados que no esperabas.
- **Comportamiento.** Abre la rama y pruébala. Un diff limpio no garantiza que la pantalla se vea o funcione bien.

Si el cambio toca datos o permisos, lee antes [[frontend-vs-backend|frontend vs. backend]] para confirmar que la regla vive en el lugar correcto. Para revisar código que no escribiste, [[leer-codigo-sin-saber-programar|leer código sin saber programar]] da las preguntas mínimas. Los criterios que revisas salen de un [[prd-para-agentes|PRD para agentes]] o de una [[spec-driven-development|especificación]] escrita antes de empezar.

## ¿Cuándo no hace falta una rama?

Para la corrección de un texto en tu propio proyecto, una rama puede ser más trámite que valor. Las ramas y los pull requests cobran sentido cuando el cambio toca varios archivos, cuando otra persona debe revisarlo o cuando lo que se rompe puede afectar a usuarios. Un criterio útil: si no te importaría descartar el cambio entero, puede ir directo; si te importaría, usa una rama.

## Ejemplo

Ejemplo ilustrativo: un diseñador necesita cambiar el color de los botones de un sitio y, al mismo tiempo, quiere que la IA reescriba la página de precios. Crea dos ramas: `colores-botones` y `reescribir-precios`. La primera se integra en un día. La segunda tarda una semana y pasa por revisión de una persona de contenidos, que comenta dos párrafos. Al revisar el diff de los precios, el diseñador nota que la IA también modificó la plantilla de la página de contacto, algo que no había pedido. Lo pide quitar antes de integrar. Como cada cambio tiene su pull request, el cambio de color no tuvo que esperar a los precios y el cambio extra no llegó a producción.

## Cómo aplicarlo mañana

1. Antes de pedir el próximo cambio a la IA, crea una rama con un nombre de dos o tres palabras que describa la tarea.
2. Escribe la descripción del pull request antes de abrirlo: qué cambió, por qué y cómo se prueba. Si no puedes escribirla, el cambio todavía no está listo para revisión.
3. Revisa el diff completo y marca cada criterio de la tarea antes de aprobar.
4. Cuando el cambio esté integrado, borra la rama. Las ramas viejas confunden más de lo que ayudan.

Un pull request también documenta decisiones: cuando una revisión cambia una regla, anota en la descripción por qué. Un buen título describe el resultado y no el proceso: «Corrige el color de los botones primarios» dice más que «cambios varios».

## Errores comunes

- Trabajar todo en la rama principal porque «es solo un cambio pequeño».
- Nombrar las ramas `prueba2` o `cambios-final`.
- Abrir un pull request sin descripción, de modo que nadie sabe qué revisar.
- Aprobar sin leer el diff, o leer solo las líneas verdes.
- Dejar ramas viejas abiertas durante meses, con cambios que ya no encajan.
- Mezclar varios asuntos en un mismo pull request.

## Fuentes

- GitHub Docs, "GitHub flow" (ramas, commits, pull requests, merge y borrado de la rama): [https://docs.github.com/en/get-started/using-github/github-flow](https://docs.github.com/en/get-started/using-github/github-flow)
- GitHub Docs, "About pull request reviews" (tipos de revisión y aprobaciones exigidas por administradores): [https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)
- GitHub Docs, "About pull requests" (pestañas de un pull request, rama de origen y destino, borradores): [https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)


---

Source: https://www.fernandoux.com/es/wiki/ia/ramas-y-pull-requests/