Git Workflows: GitFlow vs GitHub Flow vs Trunk-Based vs Release Flow

# Crear feature branch desde develop
git checkout develop
git pull origin develop
git checkout -b feature/user-authentication

# Desarrollo...
git add .
git commit -m "Add JWT token validation"

# Push y crear pull request a develop
git push origin feature/user-authentication

# Crear release branch desde develop (fin de sprint)
git checkout develop
git checkout -b release/1.2.0

# Solo bug fixes en release branch
git commit -m "Fix: Update copyright year"
git commit -m "Bump version to 1.2.0"

# Merge a main (producción)
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin main --tags

# Merge back a develop (traer fixes)
git checkout develop
git merge --no-ff release/1.2.0
git push origin develop

# Eliminar release branch
git branch -d release/1.2.0

# Crear hotfix desde main (producción rota)
git checkout main
git checkout -b hotfix/sql-injection-cve-2024-1234

# Fix crítico
git commit -m "Fix: Sanitize SQL inputs"

# Merge a main
git checkout main
git merge --no-ff hotfix/sql-injection-cve-2024-1234
git tag -a v1.2.1 -m "Hotfix: SQL injection patch"
git push origin main --tags

# Merge a develop (evitar regresión)
git checkout develop
git merge --no-ff hotfix/sql-injection-cve-2024-1234
git push origin develop

# Si existe release branch activo, merge ahí también
git checkout release/1.3.0
git merge --no-ff hotfix/sql-injection-cve-2024-1234

# Proteger main: solo merges desde release/hotfix
az repos policy merge-strategy create \
  --repository-id <REPO_ID> \
  --branch main \
  --blocking true \
  --enabled true \
  --use-squash-merge false

# Proteger develop: require pull request + 2 reviewers
az repos policy approver-count create \
  --repository-id <REPO_ID> \
  --branch develop \
  --blocking true \
  --enabled true \
  --minimum-approver-count 2 \
  --creator-vote-counts false

git checkout main
git pull origin main
git checkout -b feature/dark-mode

# Desarrollo
git add .
git commit -m "Add dark mode toggle component"
git push origin feature/dark-mode

# GitHub CLI
gh pr create \
  --title "Feature: Dark mode support" \
  --body "Implements dark mode with system preference detection. Closes #456" \
  --base main \
  --head feature/dark-mode

# Reviewers prueban en staging URL
# https://pr-123.staging.example.com

# Si hay bugs, push nuevos commits
git commit -m "Fix: Dark mode contrast ratio"
git push origin feature/dark-mode
# CI/CD redeploy automáticamente

# Opción A: Deploy manual antes de merge
# Deploy feature branch a producción para validar
vercel deploy --prod --token=$VERCEL_TOKEN

# Si deploy exitoso → merge PR
gh pr merge 123 --squash --delete-branch

# 1. PR abierto → Deploy automático a staging
https://pr-123.staging.example.com

# 2. Review + QA en staging
# 3. Si staging OK → Deploy a producción (canary/blue-green)
# 4. Si producción OK durante 30min → Merge PR a main
# 5. Si producción falla → NO merge, fix en feature branch

# Convierte 10 commits en feature branch → 1 commit en main
gh pr merge 123 --squash --delete-branch

# Resultado: Historia main limpia
# main: feat: Add dark mode (PR #123)
#   En lugar de:
#   - WIP dark mode
#   - Fix typo
#   - Update tests
#   - Fix linter
#   ...

gh pr merge 123 --merge
# Crea merge commit explícito en main

gh pr merge 123 --rebase
# Replay commits de feature branch sobre main
# Historia lineal sin merge commits

# Sin branches: commit directo a trunk
git checkout main
git pull --rebase origin main

# Cambio pequeño (<2h trabajo)
git add .
git commit -m "feat: Add user avatar upload"
git push origin main

# CI/CD deploy automático a producción en <10 min

# Para cambios que requieren >2h
git checkout -b quick-fix-validation
# Trabajo durante 4-8 horas
git commit -m "Fix: Email validation regex"

# Merge mismo día (NO pull request largo)
git checkout main
git pull --rebase origin main
git merge quick-fix-validation --ff-only
git push origin main
git branch -d quick-fix-validation

# Commit código incomplete a main (con flag disabled)
git commit -m "feat: New checkout flow (behind feature flag)"
git push origin main

# Deploy a producción → feature oculta para usuarios
# Developers pueden testear con flag enabled

# Cuando feature completa → enable flag
featureFlags.enable('new-checkout-flow', { rollout: 10 }); // 10% usuarios
# Gradual rollout: 10% → 50% → 100%

# Eliminar flag cuando 100% estable
git commit -m "refactor: Remove new-checkout-flow feature flag"

# .husky/pre-commit
#!/bin/bash
npm run lint
npm run test:unit
npm run build

# Si falla → commit bloqueado

# Azure DevOps: Forzar squash/rebase (no merge commits)
az repos policy merge-strategy create \
  --repository-id <REPO_ID> \
  --branch main \
  --blocking true \
  --use-squash-merge true

# GitHub: Linear history
gh api repos/:owner/:repo/branches/main/protection \
  --method PUT \
  --field required_linear_history=true

# Google: 1 repo gigante, 1 branch (trunk)
# 2+ billion lines of code
# 25,000+ developers
# 40,000+ commits/día

# Bazel: Builds incrementales ultra-rápidos
bazel build //services/search/...
# Solo rebuilds changed dependencies (graph-based)

# Tests afectados solamente
bazel test --test_tag_filters=affected //...

# Developer crea topic branch (1-3 días)
git checkout -b users/alice/add-oauth-provider

# Commits frecuentes
git commit -m "Add Google OAuth client ID config"
git commit -m "Implement OAuth callback handler"
git push origin users/alice/add-oauth-provider

# Pull request a main (NO a release branch)
az repos pr create \
  --title "Add Google OAuth provider" \
  --source-branch users/alice/add-oauth-provider \
  --target-branch main \
  --reviewers security-team

# Auto-complete PR después de approvals
az repos pr update \
  --id 1234 \
  --auto-complete true \
  --squash true \
  --delete-source-branch true

# Resultado: 1 commit limpio en main
# "Add Google OAuth provider (#1234)"

# Fin de Sprint 129 → crear release branch
git checkout main
git pull origin main
git checkout -b releases/M129

# Tag release
git tag -a v129.0 -m "Release Sprint 129"
git push origin releases/M129 --tags

# Deploy release branch a producción (ring-based)
# Ring 0 (internal): 1%   → 1 hora monitoring
# Ring 1 (early):    10%  → 24 horas monitoring
# Ring 2 (broad):    50%  → 48 horas monitoring
# Ring 3 (full):     100% → release completo

# Bug crítico descubierto en producción (releases/M129)
# SIEMPRE fix en main primero (evita regression en M130)

git checkout main
git checkout -b users/alice/hotfix-sql-injection

git commit -m "Fix: Sanitize SQL query parameters"
git push origin users/alice/hotfix-sql-injection

# Pull request a main
az repos pr create \
  --title "Hotfix: SQL injection vulnerability" \
  --source-branch users/alice/hotfix-sql-injection \
  --target-branch main

# Merge a main
az repos pr update --id 1250 --auto-complete true --squash true

# Cherry-pick a release branch (Azure DevOps UI o CLI)
git checkout releases/M129
git cherry-pick <commit-hash-from-main>
git push origin releases/M129

# Tag hotfix
git tag -a v129.1 -m "Hotfix: SQL injection patch"
git push origin releases/M129 --tags

# Deploy v129.1 a producción (fast-track rings)

# Topic branches (short-lived, 1-5 días)
users/alice/feature-name
users/bob/bugfix-description
users/carol/refactor-component

# Release branches (long-lived, 3-6 meses)
releases/M129  # Sprint 129
releases/M130  # Sprint 130

# Tags
v129.0  # Release Sprint 129
v129.1  # Hotfix 1 Sprint 129
v130.0  # Release Sprint 130

# Proteger main: require PR + 2 reviewers + CI pass
az repos policy approver-count create \
  --branch main \
  --repository-id <REPO_ID> \
  --blocking true \
  --enabled true \
  --minimum-approver-count 2 \
  --creator-vote-counts false

az repos policy build create \
  --branch main \
  --repository-id <REPO_ID> \
  --blocking true \
  --enabled true \
  --build-definition-id <BUILD_ID> \
  --display-name "PR Validation" \
  --queue-on-source-update-only true

# Proteger release branches: solo cherry-picks desde main
az repos policy merge-strategy create \
  --branch releases/* \
  --repository-id <REPO_ID> \
  --blocking true \
  --use-squash-merge false \
  --allow-no-fast-forward false

# Desarrollo en main
git checkout main
git checkout -b feature/new-dashboard
git commit -m "Add analytics dashboard"
git push origin feature/new-dashboard

# Merge a main (como GitHub Flow)
git checkout main
git merge feature/new-dashboard

# Deploy a staging (automático CI/CD)
git checkout staging
git merge main
git push origin staging
# CI/CD → Deploy to staging environment

# Si staging OK → Deploy a production
git checkout production
git merge staging
git push origin production
# CI/CD → Deploy to production environment

# Para software con versiones (mobile apps, libraries)
git checkout main
git checkout -b release/2.3

# Deploy release branch a stores/registries
# Hotfixes en release branch
git checkout -b hotfix/2.3.1 release/2.3
git commit -m "Fix crash on Android 12"
git checkout release/2.3
git merge hotfix/2.3.1
git tag v2.3.1

# Merge hotfix back a main
git checkout main
git merge hotfix/2.3.1

# Para equipos grandes con múltiples environments + versiones
main
  ↓
staging (test environment)
  ↓
pre-production (UAT environment)
  ↓
production (live environment)

# + Release branches para versiones legacy
release/2.0 (support 2.0.x)
release/3.0 (support 3.0.x)

# 1. Crear feature branch desde main
git checkout main
git pull origin main
git checkout -b feature/user-notifications

# 2. Desarrollo + commits
git add .
git commit -m "Add push notification service"
git push origin feature/user-notifications

# 3. Merge request (GitLab) o pull request
# Reviewers aprueban, CI/CD tests pasan

# 4. Merge a main
git checkout main
git merge --no-ff feature/user-notifications
git push origin main

# Código pasa: main → staging → production

# Step 1: Merge feature a main
git checkout main
git merge feature/payment-gateway

# Step 2: Promote main to staging (automático o manual)
git checkout staging
git merge main
git push origin staging
# GitLab CI/CD → Deploy to staging.example.com

# Step 3: QA testing en staging (manual)
# Testers validan en staging environment

# Step 4: Promote staging a production (manual approval)
git checkout production
git merge staging  # O merge main directamente
git push origin production
# GitLab CI/CD → Manual approval → Deploy to example.com

# Bug crítico en production

# Opción A: Fix en main, fast-forward a production
git checkout main
git checkout -b hotfix/security-patch
git commit -m "Fix: SQL injection vulnerability"
git checkout main
git merge hotfix/security-patch

# Skip staging, merge directo a production (emergency)
git checkout production
git merge main
git push origin production

# Opción B: Cherry-pick a production (si main divergió mucho)
git checkout production
git cherry-pick <commit-hash-from-main>
git push origin production

# Sync staging después
git checkout staging
git merge main

# Crear feature branch desde main (igual que GitHub Flow)
git checkout main
git pull origin main
git checkout -b feature/shopping-cart

# Desarrollo
git commit -m "Add cart service"
git commit -m "Add cart UI components"
git push origin feature/shopping-cart

# Pull request a main
gh pr create --base main --head feature/shopping-cart

# Merge a main (squash)
gh pr merge --squash --delete-branch

# Cuando listo para release → crear release branch
git checkout main
git checkout -b release/2.0.0

# Bump version, changelog, release notes
git commit -m "chore: Bump version to 2.0.0"

# Bug fixes en release branch (como GitFlow)
git commit -m "fix: Validation error in checkout"
git commit -m "fix: Typo in confirmation email"

# Tag release
git tag -a v2.0.0 -m "Release 2.0.0"
git push origin release/2.0.0 --tags

# Deploy release branch a producción

# Merge release branch BACK to main (diferencia con GitFlow)
git checkout main
git merge --no-ff release/2.0.0
git push origin main

# Release branch puede mantenerse (para hotfixes) o eliminarse

# Opción A: Hotfix desde release branch (si existe)
git checkout release/2.0.0
git checkout -b hotfix/2.0.1
git commit -m "fix: Critical security patch"

git checkout release/2.0.0
git merge hotfix/2.0.1
git tag -a v2.0.1 -m "Hotfix 2.0.1"
git push origin release/2.0.0 --tags

# Merge hotfix a main
git checkout main
git merge hotfix/2.0.1
git push origin main

# Opción B: Hotfix desde main (si no hay release branch)
git checkout main
git checkout -b hotfix/critical-fix
git commit -m "fix: Emergency patch"
git checkout main
git merge hotfix/critical-fix
git tag -a v2.0.1 -m "Hotfix 2.0.1"

# Release branch solo durante RC testing (1-2 semanas)
git checkout -b release/3.0.0
# Testing + bug fixes
git tag v3.0.0
git checkout main
git merge release/3.0.0
git branch -d release/3.0.0  # Eliminar después de release

# Mantener release branches para support largo plazo
release/2.0  # Support 2.0.x (6 meses)
release/3.0  # Support 3.0.x (current)
main         # Development 4.0

# 1. Crear feature branch
git checkout main
git pull origin main
git checkout -b feature/add-search

# 2. Desarrollo
git add src/search/
git commit -m "Add full-text search with Elasticsearch"
git push origin feature/add-search

# 3. Pull request
gh pr create --base main --head feature/add-search

# 4. Code review + CI
# 5. Merge (squash/merge/rebase según preferencia team)
gh pr merge --squash --delete-branch

# 6. Pull main actualizado
git checkout main
git pull origin main

# 1. Merge develop a main (one-time)
git checkout main
git merge develop --ff-only
git push origin main

# 2. Eliminar develop branch
git push origin --delete develop

# 3. Feature branches desde main (no desde develop)
# 4. Release branches merge back a main

# 1. Eliminar develop branch (como OneFlow)
git checkout main
git merge develop --ff-only
git push origin main
git push origin --delete develop

# 2. Eliminar release branches long-lived
# 3. Habilitar CD pipeline (deploy on merge to main)
# 4. Feature flags para features incompletas

# 1. Crear staging branch desde main
git checkout -b staging main
git push origin staging

# 2. Crear production branch desde staging
git checkout -b production staging
git push origin production

# 3. Workflow: main → staging → production
# 4. Configurar GitLab CI/CD environments

# 1. Eliminar environment branches (staging/production)
git push origin --delete staging production

# 2. Deploy directamente desde main
# 3. CI/CD deploy on merge to main

# 1. Reducir lifetime branches (<24h)
# 2. Implementar feature flags
# 3. Commits más frecuentes (daily)
# 4. Fast CI/CD (<5 min)

# 1. Mantener main como trunk
# 2. Crear release branches al fin de sprint
git checkout -b releases/M1 main
# 3. Hotfixes via cherry-pick

# 1. Release branches long-lived (no merge back)
# 2. Cherry-pick hotfixes en lugar de merge
# 3. Sprint cadence (crear release cada N semanas)

# ❌ BAD: Branch vive 6 semanas
git log --oneline feature/new-api
# 2024-09-01: Start new API
# 2024-10-15: Finish new API (89 commits, 5000 LoC changed)

# ✅ GOOD: Branch vive 2 días
git log --oneline feature/api-user-endpoint
# 2024-10-13: Add user endpoint (3 commits, 150 LoC)

# Gran feature: Rewrite API (6 semanas)
# Dividir en:
feature/api-models         # 2 días
feature/api-user-endpoint  # 2 días
feature/api-auth-endpoint  # 3 días
feature/api-data-endpoint  # 2 días
# Total: 9 días distribuidos en 6 semanas (parallel + smaller PRs)

# ❌ BAD: 1 commit gigante al final
git commit -m "Implement entire checkout flow" # 2000 LoC

# ✅ GOOD: Commits incrementales
git commit -m "Add checkout page component"       # 150 LoC
git commit -m "Integrate payment gateway"         # 200 LoC
git commit -m "Add order confirmation email"      # 100 LoC
git commit -m "Add checkout flow tests"           # 300 LoC

# Daily: actualizar feature branch con main
git checkout feature/my-feature
git fetch origin
git rebase origin/main  # o merge si prefieres
git push --force-with-lease origin feature/my-feature

# ❌ Historia main sucia
* feat: Add login
* WIP
* Fix typo
* Linter errors
* Final fixes
* Merge feature/login

# ✅ Historia main limpia (squash)
* feat: Add login with OAuth support (#234)

# Tipos de branches
feature/  → Nuevas features
bugfix/   → Bug fixes
hotfix/   → Emergency production fixes
release/  → Release branches
docs/     → Documentation updates

# Con ticket ID
feature/JIRA-1234-user-authentication
bugfix/GH-456-fix-memory-leak

# Con username (large teams)
users/alice/feature-oauth
users/bob/bugfix-validation

# Simple: main + feature branches
# Manual QA, deploy semanal
# Sin CI/CD inicial

git checkout -b feature/user-signup
# Desarrollo 3 días
gh pr create --base main
# Manual review + test en staging
gh pr merge --squash
# Deploy manual viernes

# CD pipeline implementado
# Deploy múltiple/día
# Feature flags para features grandes

git checkout -b feature/premium-tier
# Feature flag: premium_tier_enabled = false
git push origin feature/premium-tier

# CI/CD deploy a staging automático
# Habilitar flag para testing interno
featureFlags.enable('premium_tier_enabled', { users: ['internal'] })

# Merge → deploy a prod (flag disabled para users)
gh pr merge --squash

# Gradual rollout
featureFlags.enable('premium_tier_enabled', { rollout: 10 }) # 10%
featureFlags.enable('premium_tier_enabled', { rollout: 100 }) # 100%

# Sprint 3-semanas
# 200+ PRs/día merging a main
# Release branch por sprint

# Developer workflow
git checkout -b users/alice/JIRA-5678-api-v3
# 2 días desarrollo
az repos pr create --target-branch main

# Sprint end (cada 3 semanas)
git checkout -b releases/2024.11
# Deploy ring-based (1% → 10% → 50% → 100%)

# Hotfix mid-sprint
git checkout -b users/bob/hotfix-auth
# Fix en main
az repos pr complete
# Cherry-pick to releases/2024.11

# Commits directos a trunk (o branches <24h)
# 40,000+ commits/día
# Tests ultra-rápidos (<5 min)

# Presubmit tests (antes de commit)
bazel test //services/search:unit_tests  # 30 sec

# Commit
git commit -m "Optimize search ranking algorithm"
git push origin main

# Postsubmit tests (async, post-commit)
bazel test //...  # Full test suite, 30 min

# Auto-rollback si postsubmit falla

# ~/.gitconfig
[alias]
  # Sync con main rápido
  sync = !git fetch origin && git rebase origin/main

  # Historia limpia
  lg = log --graph --oneline --all --decorate

  # Squash últimos N commits
  squash = "!f() { git reset --soft HEAD~$1 && git commit; }; f"

  # Limpiar branches mergeadas
  clean-merged = "!git branch --merged | grep -v '\\*\\|main\\|develop' | xargs -n 1 git branch -d"

# Crear PR desde CLI
az repos pr create \
  --title "feat: Add Redis caching layer" \
  --description "Implements Redis cache for API responses. Reduces latency 70%." \
  --source-branch feature/redis-cache \
  --target-branch main \
  --reviewers alice@contoso.com bob@contoso.com

# Auto-complete PR con policies
az repos pr update \
  --id 1234 \
  --auto-complete true \
  --squash true \
  --delete-source-branch true

# Crear PR con labels/reviewers
gh pr create \
  --title "feat: Add Stripe payment integration" \
  --body "Closes #456" \
  --base main \
  --head feature/stripe \
  --reviewer alice,bob \
  --label enhancement,high-priority

# Merge con squash
gh pr merge 123 --squash --delete-branch --admin