Hybrid GitFlow para Indie Serio

🌳Estructura de Branches

main ──●──●──●──●──●──●──● (v1.2.1, v1.2.2, v2.0.0) │ │ │ │ │ └─ merge from develop │ └─ hotfix/critical-bug └─ feature/small-fix develop ──●──●──●──●──●──────● │ │ │ │ │ │ │ │ │ │ └─ v2.0.0-rc.1 │ │ │ └─ v2.0.0-beta.2 │ │ └─ v2.0.0-beta.1 │ └─ v2.0.0-alpha.2 └─ v2.0.0-alpha.1 feature/ ──●──●──●──● └─ merge to develop or main

📋 Roles de Branches:

🟢 main: Producción (auto-tag, auto-deploy)
🟡 develop: Staging para major versions
🔵 feature/*: Desarrollo temporal
🔴 hotfix/*: Fixes críticos

🚦Árbol de Decisión

🤔 ¿Qué tipo de cambio es?

📦 Cambio Menor (patch/minor)

→ Directo a main

• Bug fixes
• Mejoras pequeñas
• Nuevas features simples

🚀 Cambio Mayor (major)

→ Develop primero

• Breaking changes
• Refactoring grande
• Nuevas features complejas

🔥 Hotfix Crítico

→ Directo a main

• Bugs críticos
• Vulnerabilidades
• Fallos de producción

⚡Flujo para Cambios Menores

1

Feature Branch desde Main

Para bugs y features pequeñas

git checkout main
git pull origin main
git checkout -b fix/email-validation

2

Desarrollo + PR

Con linter y tests automáticos

git commit -m "fix: corregir validación email"
git push -u origin fix/email-validation
# Create PR → Review → Merge

3

Auto-Release

Tag y deploy automáticos

# Merge to main →
# Auto-tag: v1.2.3
# Auto-build: Docker image
# Auto-deploy: Production

🧪Flujo para Major Versions

Alpha

v2.0.0-alpha.1

1-2 semanas

Desarrollo inicial: Funcionalidad básica implementada, muchos bugs esperados

git checkout develop
git checkout -b feature/new-auth-system
# ... desarrollo ...
git checkout develop
git merge feature/new-auth-system
git tag v2.0.0-alpha.1
git push origin v2.0.0-alpha.1

Beta

v2.0.0-beta.1

2-3 semanas

Feature complete: Funcionalidad completa, testing intensivo

# Después de más desarrollo y testing
git tag v2.0.0-beta.1
git push origin v2.0.0-beta.1
# → Deploy a staging environment

RC

v2.0.0-rc.1

1 semana

Release candidate: Listo para producción, último testing

git tag v2.0.0-rc.1
git push origin v2.0.0-rc.1
# → Final testing, user acceptance

Stable

v2.0.0

∞

Release final: Merge a main, auto-deploy

git checkout main
git merge develop
git push origin main
# → Auto-tag v2.0.0 → Production deploy

⏰Cuándo Hacer Pre-releases

📅 Guía de Timing

Pre-release	Cuándo	Duración	Criterio
Alpha	Feature 70% completa	1-2 semanas	Core funciona, puede tener bugs
Beta	Feature 90% completa	2-3 semanas	Testing intensivo, feedback users
RC	Feature 99% completa	1 semana	Solo bugs críticos, no features
Stable	Todo perfecto	Release	Cero bugs conocidos

📋Ejemplos Prácticos

Minor Change

Fix validación de email

git checkout -b fix/email-validation
git commit -m "fix: validar formato email correctamente"
git push -u origin fix/email-validation
# PR → Merge → Auto-tag v1.2.4

Major Change

Nuevo sistema de autenticación

# Develop en develop branch
git checkout develop
git checkout -b feature/oauth-system

# Serie de pre-releases
git tag v2.0.0-alpha.1  # OAuth básico
git tag v2.0.0-alpha.2  # Google/GitHub
git tag v2.0.0-beta.1   # UI completa
git tag v2.0.0-rc.1     # Testing final

# Release final
git checkout main && git merge develop
# → Auto-tag v2.0.0

Hotfix

Vulnerability crítica

git checkout -b hotfix/security-patch
git commit -m "fix: patch SQL injection vulnerability"
git push -u origin hotfix/security-patch
# Fast PR → Immediate merge → Auto-tag v1.2.5

⚙️CI/CD Configuration

# .github/workflows/auto-tag.yml
name: Auto Tag
on:
  push:
    branches: [main]  # Solo main auto-tag

# .github/workflows/prerelease.yml  
name: Manual Pre-release
on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Pre-release version'
        required: true

# .github/workflows/release.yml
name: Release
on:
  push:
    tags: ['v*']  # Cualquier tag → build

✅ Setup Recomendado

Branch protection en main y develop
Require PR reviews para main
Auto-delete feature branches
Status checks obligatorios
Auto-merge cuando checks pasan
Staging environment para develop
Production environment para main

🎯Comandos Esenciales

# Setup inicial
git checkout -b develop
git push -u origin develop

# Cambio menor (directo main)
git checkout main
git checkout -b fix/pequeño-bug
# ... PR → merge

# Feature grande (develop first)
git checkout develop
git checkout -b feature/gran-cambio
# ... merge to develop → pre-releases

# Pre-release manual
git checkout develop
git tag v2.0.0-alpha.1
git push origin v2.0.0-alpha.1

# Release final
git checkout main
git merge develop
git push origin main  # → auto-tag

Hotfix urgente
git checkout main
git checkout -b hotfix/critico
# ... fix → PR → fast merge

# Cleanup local
git checkout main
git pull origin main
git branch -d feature/nombre-branch

📊Cuándo Usar Cada Estrategia

🎯 Guía de Decisión Rápida

🔧 Directo a Main (80% del tiempo)

Usar para:

Bug fixes menores
Mejoras de UI pequeñas
Optimizaciones de performance
Actualizaciones de dependencias
Documentación
Tests adicionales

Tiempo: 1-3 días de desarrollo

🧪 Develop + Pre-releases (15% del tiempo)

Usar para:

Nuevas features complejas
Cambios de arquitectura
Breaking changes
Refactoring masivo
Integración de múltiples features
Cambios de base de datos

Tiempo: 2-8 semanas de desarrollo

🚨 Hotfix Urgente (5% del tiempo)

Usar para:

Vulnerabilidades de seguridad
Bugs que rompen funcionalidad crítica
Problemas de producción
Data corruption fixes

Tiempo: Horas, máximo 1 día

🎬Scenarios Reales

📱 Proyecto: App de E-commerce

v1.2.1

Fix: Error en cálculo de impuestos

Impacto: Bug menor, funcionalidad trabaja pero mal cálculo

Estrategia: Feature branch → Main directo

git checkout -b fix/tax-calculation
# 2 horas de fix
git commit -m "fix: corregir cálculo impuestos para EU"
# PR → Merge → Auto-tag v1.2.1 → Deploy

v2.0.0

Feature: Sistema de reviews y ratings

Impacto: Nueva funcionalidad grande, cambios en DB

Estrategia: Develop → Pre-releases → Main

# Semana 1-2: Desarrollo inicial
git checkout develop
git checkout -b feature/reviews-system
git tag v2.0.0-alpha.1  # Reviews básicos

# Semana 3-4: UI y features completas  
git tag v2.0.0-alpha.2  # UI completa
git tag v2.0.0-beta.1   # Testing público

# Semana 5: Fixes y polish
git tag v2.0.0-beta.2   # Bug fixes
git tag v2.0.0-rc.1     # Release candidate

# Semana 6: Release
git checkout main && git merge develop
# → Auto-tag v2.0.0

v1.2.2

Hotfix: Falla de pagos con Stripe

Impacto: Crítico - usuarios no pueden pagar

Estrategia: Hotfix directo a main

git checkout -b hotfix/stripe-payment-fix
# 30 minutos de fix urgente
git commit -m "fix: resolve Stripe API timeout issue"
# Fast-track PR → Immediate merge → Auto-tag v1.2.2

📈Métricas y KPIs

📊 Para Indie Serio

Métrica	Target	¿Por qué importa?
Deploy Frequency	2-3x por semana	Mantener momentum
Lead Time	< 2 días para minor	Feedback rápido
Pre-release Duration	4-6 semanas max	No bloquear progress
Hotfix Time	< 2 horas	Crítico para usuarios
Failed Deployments	< 5%	Confianza en proceso

🎯 Objetivos como Indie Serio

Mantener velocity sin sacrificar calidad
Users nunca esperan más de 1 semana por fixes
Pre-releases permiten validar antes de release
Main branch siempre deployable
Proceso predecible y documentado
Automatización reduce trabajo manual
Feedback loop rápido con usuarios

🛠️Herramientas Recomendadas

# Package.json scripts útiles
{
  "scripts": {
    "release:alpha": "npm version prerelease --preid=alpha",
    "release:beta": "npm version prerelease --preid=beta", 
    "release:rc": "npm version prerelease --preid=rc",
    "release:patch": "npm version patch",
    "release:minor": "npm version minor",
    "release:major": "npm version major"
  }
}

🔧 Stack Recomendado:

📦 Semantic Release: Auto-versioning basado en commits
🎣 Husky: Pre-commit hooks para linting
📝 Conventional Commits: Formato estándar de commits
🏷️ Auto-tag Action: Tags automáticos en GitHub
🐳 Docker: Containerización consistente
📊 GitHub Actions: CI/CD integrado
🔍 SonarCloud: Code quality analysis

⚡ Quick Commands

# GitHub CLI shortcuts
gh pr create --title "feat: nueva funcionalidad" --body "Descripción"
gh pr merge --auto --squash
gh workflow run "Manual Pre-release" -f version=v2.0.0-alpha.1

# Git aliases útiles
git config --global alias.co checkout
git config --global alias.br branch  
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.unstage 'reset HEAD --'

🔀 Hybrid GitFlow

🎯 Filosofía Híbrida

Simple para el día a día

Staging para features grandes

Auto-deploy inteligente

Quality gates

🌳Estructura de Branches

📋 Roles de Branches:

🚦Árbol de Decisión

🤔 ¿Qué tipo de cambio es?

📦 Cambio Menor (patch/minor)

🚀 Cambio Mayor (major)

🔥 Hotfix Crítico

⚡Flujo para Cambios Menores

Feature Branch desde Main

Desarrollo + PR

Auto-Release

🧪Flujo para Major Versions

⏰Cuándo Hacer Pre-releases

📅 Guía de Timing

📋Ejemplos Prácticos

Fix validación de email

Nuevo sistema de autenticación

Vulnerability crítica

⚙️CI/CD Configuration

✅ Setup Recomendado

🎯Comandos Esenciales

📊Cuándo Usar Cada Estrategia

🎯 Guía de Decisión Rápida

🔧 Directo a Main (80% del tiempo)

🧪 Develop + Pre-releases (15% del tiempo)

🚨 Hotfix Urgente (5% del tiempo)

🎬Scenarios Reales

📱 Proyecto: App de E-commerce

Fix: Error en cálculo de impuestos

Feature: Sistema de reviews y ratings

Hotfix: Falla de pagos con Stripe

📈Métricas y KPIs

📊 Para Indie Serio

🎯 Objetivos como Indie Serio

🛠️Herramientas Recomendadas

🔧 Stack Recomendado:

⚡ Quick Commands

🚀 Resumen Final para Indie Serio

✅ Lo que SÍ haces

❌ Lo que NO haces

🎯 Resultado