brainax

Ramas y pull requests

Lección 9 de 26 del curso «Vibe coding». Gratis, con animaciones y un test.

main: el sitio en vivo

Una rama (branch) es una línea aparte de commits en el proyecto. La rama principal suele llamarse main. Si el hosting está conectado al repositorio, lo que hay en main es el sitio que la gente ve ahora mismo. La línea de abajo del esquema es main. De ahí la regla: en main no se experimenta. Si rompes main, el sitio queda roto para todos mientras lo arreglas.

Una rama es una copia para probar

Ejemplo: necesitas un botón «Pedir con anticipación» en el sitio de la cafetería donde trabajas medio tiempo. Creas una rama, una copia paralela del proyecto. En el esquema sube y se llama «nuevo-boton». En ella haces todos los commits que quieras, aquí hay dos. Mientras tanto el sitio en vivo no cambia. ¿No salió? Abandonas la rama y main ni se entera.

Pull request: revisión antes de unir

Un pull request, o PR, es una solicitud de «une mi rama a main». La página del PR muestra tres cosas. El diff: qué líneas se agregaron y cuáles se borraron. Comentarios: puedes hablar de los cambios con un amigo o con la IA. Revisiones automáticas: programas prueban el código solos y ponen una palomita si todo pasó. En el esquema la rama vuelve a main justo por esa caja.

Vista previa y merge

Muchos servicios de hosting arman una vista previa de la rama: una copia aparte del sitio con su propio enlace. Es la etiqueta «enlace de vista previa» del esquema. La abres en el celular, tocas el botón nuevo y revisas que nada se haya roto. El sitio en vivo sigue intacto. ¿Todo bien? Presionas merge («unir»): los cambios de la rama pasan a main y el hosting actualiza el sitio solo.

Cómo trabajar así con un agente

El mismo esquema, solo que el código lo escribe la IA. Le das una tarea al agente y agregas: «Hazlo en una rama aparte y abre un PR». Crea la rama, hace commits y abre el PR. Tú abres la vista previa, revisas y dices qué corregir. Cuando todo funciona, el merge lo haces tú. Así un error de la IA se queda en la rama y no en el sitio en vivo.

Ponte a prueba

  1. ¿Por qué hacer una función nueva en una rama aparte?
    Respuesta correcta: Para probar sin romper el sitio en vivo en main. Una rama es una copia paralela. Ahí puedes equivocarte libremente, y main con el sitio en vivo no cambia hasta el merge.
  2. ¿Qué es un pull request?
    Respuesta correcta: Una solicitud para unir una rama a main, con diff y revisiones. Un PR es una página con lo que cambió, comentarios y revisiones automáticas. Descargar código de GitHub es pull, otra cosa.
  3. Un agente abrió un PR. ¿Qué haces antes del merge?
    Respuesta correcta: Abro la vista previa y reviso que todo funcione. La IA también se equivoca, así que la revisión final es tuya. La vista previa muestra la versión nueva antes de que llegue al sitio en vivo.

← GitHub: tu código en la nube La terminal en 10 minutos →