GitHub Flow

main siempre desplegable, ramas cortas por cambio, Pull Request y deploy tras el merge.

Contexto

Productos web o SaaS con despliegue continuo y un solo entorno de producción. Es la opción más simple que funciona para la mayoría de equipos pequeños y medianos.

Solución
  1. main siempre es desplegable.
  2. Para cada cambio creás una rama con nombre descriptivo desde main.
  3. Hacés commits y abrís un Pull Request temprano.
  4. Tras review y CI verde, se mergea a main.
  5. Se despliega desde main (idealmente automático).
BASH 
git switch -c feature/invoice-pdf
git push -u origin feature/invoice-pdf
# abrir PR → review → CI verde → merge → deploy

#Diferencia con Trunk-Based

Son parientes cercanos. GitHub Flow formaliza el Pull Request como puerta de entrada y admite ramas algo más largas; Trunk-Based empuja a ramas de horas y a integrar aún más seguido. Si tus PRs tardan días en mergearse, en la práctica ya no estás haciendo ni uno ni otro.

Cuándo NO aplicarlo
  • Software con varias versiones en producción a la vez.
  • Cuando necesitás una rama de staging con aprobaciones formales por ambiente (ver GitLab Flow).
Tradeoffs
Pro Contra
Muy simple de explicar y adoptar Sin concepto nativo de versiones/releases
Review integrado vía PR Una rama larga lo degrada a "feature branch eterna"
Deploy continuo natural Depende de CI y de que main esté siempre verde

#git #branching #github #pull-request