Modelo de branching minimalista diseñado para continuous deployment. Solo dos elementos — main y feature branches — con PRs como punto de integración y deploy inmediato tras merge.
GitHub Flow es un modelo de branching simplificado creado por GitHub en 2011 como alternativa ligera a GitFlow. Su premisa: main siempre está deployable, y cada cambio pasa por un Pull Request.
GitFlow fue diseñado para software con releases programados. Pero para equipos que hacen deploy múltiples veces al día, sus múltiples ramas (develop, release/*, hotfix/*) agregan fricción sin beneficio.
GitHub Flow reduce todo a lo esencial:
main: ──●────●────●────●────●──
\ / \ / \ /
feature: ● ● ●
main siempre es deployable — cualquier commit en main puede ir a producciónfeature/add-login, fix/header-overflow# 1. Crear rama desde main actualizado
git checkout main
git pull origin main
git checkout -b feature/user-notifications
# 2. Trabajar y hacer commits
git add .
git commit -m "feat: add notification preferences UI"
git push -u origin feature/user-notifications
# 3. Abrir PR en GitHub
gh pr create --title "feat: user notifications" --body "Adds notification preferences"
# 4. Iterar basado en review
git commit -m "fix: address review comments"
git push
# 5. Merge después de aprobación (squash recomendado)
gh pr merge --squash
# 6. Deploy automático (CI/CD se encarga)
# main → staging → producciónIdeal para:
Considerar alternativas cuando:
| Aspecto | GitHub Flow | GitFlow |
|---|---|---|
| Ramas permanentes | 1 (main) | 2 (main, develop) |
| Ramas temporales | feature/* | feature/*, release/*, hotfix/* |
| Complejidad | Mínima | Alta |
| Deploy | Continuo | Por release |
| Hotfixes | Igual que features | Rama especial desde main |
| Ideal para | Web apps, SaaS | Software versionado, enterprise |
Permiten mergear código incompleto a main sin exponerlo a usuarios:
if (featureFlags.isEnabled('new-checkout')) {
return <NewCheckout />;
}
return <LegacyCheckout />;Beneficios:
Deployar la rama antes de mergear para validar en un entorno real:
# .github/workflows/branch-deploy.yml
on:
pull_request:
types: [labeled]
jobs:
deploy-preview:
if: github.event.label.name == 'deploy-preview'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: ./deploy-to-preview.shEstructura los mensajes para generar changelogs automáticos:
feat: add user notifications
fix: resolve header overflow on mobile
docs: update API documentation
chore: upgrade dependencies
name: CI/CD
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
- run: npm run lint
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run build
- run: ./deploy.shGitHub Flow es el modelo de branching más adoptado en equipos que practican continuous delivery. Su simplicidad — una sola rama principal, feature branches cortas, deploy tras merge — elimina la ceremonia de modelos más complejos como GitFlow y reduce el tiempo entre escribir código y ponerlo en producción.
Sistema de control de versiones distribuido creado por Linus Torvalds en 2005. Fundamento de todo flujo de desarrollo moderno — desde commits locales hasta colaboración global.
Plataforma de desarrollo colaborativo construida sobre Git. Más que hosting de repositorios — es el hub central para code review, CI/CD, gestión de proyectos y colaboración open source.
Modelo de branching para Git propuesto por Vincent Driessen en 2010. Define ramas con roles fijos (main, develop, feature, release, hotfix) para gestionar releases estructurados.
Estrategia de organización de código donde múltiples proyectos coexisten en un único repositorio, compartiendo dependencias, configuración y herramientas de build.
Continuous Integration y Continuous Delivery/Deployment — prácticas que automatizan la integración de código, testing y entrega a producción. Fundamento de la ingeniería de software moderna.