Estrategias de flujo de trabajo de Git para equipos en crecimiento

Git es fácil de aprender y difícil de usar bien en equipo. En el momento en que pasas de desarrollar en solitario a tener dos o más personas haciendo commits al mismo repositorio, las decisiones de workflow empiezan a acumularse. Una mala estrategia de branching genera conflictos de merge, bloquea los despliegues y erosiona la confianza en el proceso de release.

Los tres workflows que hay que conocer

La mayoría de los equipos termina usando una de tres estrategias, o un híbrido. Cada una tiene compromisos claros.

La elección correcta depende de la cadencia de releases, el tamaño del equipo y la madurez del CI, no de la preferencia personal.

Trunk-Based Development

En trunk-based development, todos hacen commit directamente a main (o a una rama de vida muy corta que se fusiona en cuestión de horas). Los feature flags controlan el trabajo incompleto.

# Short-lived branch — lives for hours, not days
git checkout -b feat/add-discount-field
# ... make changes, commit ...
git push origin feat/add-discount-field
# Open PR, get review, merge same day

// Feature flag gates incomplete work in production
export function calculatePrice(item: CartItem): number {
  const base = item.price * item.quantity;
 
  if (featureFlags.isEnabled("volume-discounts")) {
    return applyVolumeDiscount(base, item.quantity);
  }
 
  return base;
}

La restricción clave: las ramas deben tener vida corta. Si una rama vive más de uno o dos días, no estás haciendo trunk-based development — estás haciendo ramas de features de larga duración con pasos extra.

GitHub Flow

GitHub Flow es el workflow más común para equipos de producto. Una rama de larga duración (main), ramas de features para cada cambio, pull requests para revisión.

# Create a feature branch from main
git checkout main
git pull origin main
git checkout -b feat/user-profile-redesign
 
# Work on the feature, commit often
git add -A
git commit -m "refactor: extract ProfileHeader component"
git commit -m "feat: add avatar upload to profile page"
 
# Push and open a PR
git push origin feat/user-profile-redesign

El modo de fallo típico son las ramas obsoletas. Cuando una rama de feature vive una semana y main avanza, los conflictos de merge se acumulan y las revisiones se vuelven tediosas.

// ❌ Giant PR after two weeks of isolated work
// 47 files changed, 2,300 additions, 800 deletions
// Reviewer: "... I'll look at it tomorrow" (never does)
 
// ✅ Stacked PRs — small, reviewable, shippable
// PR 1: Add ProfileHeader component (3 files, 120 lines)
// PR 2: Add avatar upload endpoint (2 files, 80 lines)
// PR 3: Wire upload to ProfileHeader (4 files, 60 lines)

Divide el trabajo en PRs pequeños y fusionables de forma independiente. Cada PR debería poder revisarse en menos de 15 minutos.

GitFlow y cuándo lo necesitas de verdad

GitFlow introduce las ramas develop, release/* y hotfix/* sobre main. Está pensado para productos que lanzan releases versionados: software de escritorio, apps móviles con revisión de app store, o librerías con semver.

# Start a release branch from develop
git checkout develop
git checkout -b release/2.4.0
 
# Fix last-minute bugs on the release branch
git commit -m "fix: correct currency formatting in invoice PDF"
 
# Merge to main and tag
git checkout main
git merge release/2.4.0
git tag -a v2.4.0 -m "Release 2.4.0"
 
# Back-merge to develop
git checkout develop
git merge release/2.4.0

Si despliegas continuamente desde main, GitFlow añade ceremonia sin beneficio. Resuelve el problema específico de mantener varios canales de release en simultáneo.

Disciplina en los mensajes de commit

Sin importar el workflow, los mensajes de commit son documentación. Un buen historial de commits es un changelog buscable.

# ❌ Useless messages
git commit -m "fix stuff"
git commit -m "WIP"
git commit -m "updates"
 
# ✅ Conventional commits — searchable, parseable
git commit -m "fix: prevent duplicate charges on retry"
git commit -m "feat: add webhook signature verification"
git commit -m "refactor: extract payment gateway interface"

Conventional Commits (feat:, fix:, refactor:, chore:, docs:) habilitan changelogs automáticos, versionado semántico y un git log con sentido.

Proteger Main

Todo equipo necesita guardrails en la rama principal. Como mínimo:

# Example GitHub branch protection rules
branches:
  main:
    protection:
      required_pull_request_reviews:
        required_approving_review_count: 1
      required_status_checks:
        strict: true
        contexts:
          - "ci/tests"
          - "ci/lint"
          - "ci/typecheck"
      enforce_admins: true

Nada de pushes directos a main. Nada de mergear sin pasar el CI. Nada de saltarse las reglas "solo por esta vez" — así es como se rompe producción un viernes a las 5 PM.

Gestionar los conflictos de merge de forma proactiva

La mayoría de los conflictos de merge vienen de dos fuentes: ramas de larga duración y archivos compartidos que todos editan (rutas, configuraciones, barrel exports).

// ❌ Single barrel file that every feature touches
// src/components/index.ts — guaranteed conflict zone
export { Button } from "./Button";
export { Modal } from "./Modal";
export { UserCard } from "./UserCard"; // PR A adds this
export { InvoiceTable } from "./InvoiceTable"; // PR B adds this — conflict
 
// ✅ Import directly — no shared barrel file
import { UserCard } from "@/components/UserCard";
import { InvoiceTable } from "@/components/InvoiceTable";

El otro remedio es hacer rebase con frecuencia. Si tu rama vive más de un día, haz rebase sobre main a diario para detectar conflictos temprano, cuando todavía son pequeños.

Puntos clave

1. Elige un workflow que se ajuste a tu cadencia de releases — no el que mejor se vea en un diagrama
2. Mantén las ramas de vida corta sin importar qué workflow elijas
3. Los PRs pequeños se revisan más rápido y se fusionan mejor que los monolíticos
4. Los conventional commits hacen tu historial buscable y tus changelogs automáticos
5. Protege main con gates de CI — sin excepciones, sin bypasses
6. Haz rebase con frecuencia para detectar conflictos de merge mientras siguen siendo pequeños