Flujo de Trabajo Git

Overview

Un flujo de trabajo Git define cómo tu equipo usa ramas para gestionar trabajo paralelo, revisar cambios y mantener la rama principal estable. El flujo descrito aquí — a menudo llamado “GitHub Flow” — es ligero, escala desde desarrolladores solitarios hasta equipos grandes, e integra naturalmente con pipelines de CI/CD.

When to Use

Usa este flujo cuando:

• Trabajes en un equipo donde múltiples desarrolladores tocan la misma base de código. Consulta GitHub Actions para automatización CI/CD.
• Quieras que cada cambio sea revisado antes de llegar a producción. Consulta Unit Testing para validación pre-merge.
• Tu proyecto haga deployment continuo desde la rama principal. Consulta Docker Basics para despliegues containerizados.
• Necesites un camino claro de rollback cuando algo salga mal. Consulta Feature Flags para toggles instantáneos.

Solution

Modelo de Branching

main  ───────────────────────────────────────────►
       \
feature/login   ──────────►  (PR → review → merge)
       \
feature/payments  ────────►  (PR → review → merge)

Comandos Diarios

# Iniciar una nueva feature
$ git checkout main
$ git pull origin main
$ git checkout -b feature/descripcion

# Hacer commits
$ git add .
$ git commit -m "feat: add password reset endpoint"

# Push y abrir pull request
$ git push -u origin feature/descripcion
# Abrir PR en GitHub, solicitar review, esperar que CI pase

# Después del merge, limpiar
$ git checkout main
$ git pull origin main
$ git branch -d feature/descripcion

Mantener un Historial Limpio (opcional)

# Antes de mergear, rebase sobre main más reciente
$ git fetch origin
$ git rebase origin/main

# Si tienes commits locales desordenados, haz squash
$ git rebase -i HEAD~3
# Cambia "pick" a "squash" para los commits que quieras combinar

Convención de Mensajes de Commit (Conventional Commits)

feat: add user authentication
fix: resolve race condition in checkout
docs: update API reference for v2
refactor: extract payment service

Explanation

• main siempre es deployable: solo mergea código que pase tests y review.
• Las ramas de feature aíslan el trabajo: cada feature, bugfix o experimento vive en su propia rama.
• Los pull requests enforce calidad: la revisión de código atrapa bugs, comparte conocimiento y mantiene estándares consistentes.
• Rebase vs. merge: rebase reescribe tu rama sobre main para un historial lineal; merge preserva la secuencia exacta de eventos. Usa rebase para limpieza personal, merge para historial de equipo.

Variants

Modelo	Ideal Para	Complejidad
GitHub Flow	Deployment continuo, equipos pequeños	Baja
Git Flow	Releases programados, ciclos de QA	Media
Trunk-based	Monorepos, CI muy rápido	Baja
Release branches	Versiones con soporte a largo plazo	Media

Lo que funciona

• Mantén ramas de corta vida: una rama abierta por semanas acumula conflictos de merge y código obsoleto. Apunta a días, no semanas.
• Escribe mensajes de commit significativos: explica por qué, no solo qué. Tu yo futuro (y tus compañeros) te lo agradecerán.
• Revisa tu propio PR primero: lee el diff antes de solicitar reviewers. Atraparás problemas obvios.
• Automatiza con CI: ejecuta lint, tests y scans de seguridad en cada pull request antes de que alguien revise.
• Protege main: requiere reviews de PR, CI exitoso y ramas actualizadas antes de mergear a main.

Common Mistakes

• Ramas de larga duración: cuanto más vive una rama, más difícil es mergearla. Haz rebase frecuentemente.
• Commit directo a main: incluso en proyectos solitarios, usar ramas mantiene tu historial limpio y el rollback fácil.
• Pull requests gigantes: PRs con cientos de archivos son imposibles de revisar bien. Divide capacidades grandes en PRs apiladas.
• Ignorar conflictos de merge: resolver conflictos apresuradamente sin entender ambos lados introduce bugs.
• Historial de commits desordenado: “fix”, “fix again”, “actually fix” hacen que git blame sea inútil. Haz squash o amend antes de pushear.

Tips de Rendimiento

1. Usa shallow clones para CI. Reduce el tiempo de clonación trayendo solo el último commit:

$ git clone --depth 1 https://github.com/org/repo.git
# Para una rama específica:
$ git clone --depth 1 --branch main https://github.com/org/repo.git

2. Usa git sparse-checkout para monorepos. Haz checkout solo de los directorios que necesitas:

$ git clone --no-checkout https://github.com/org/monorepo.git
$ cd monorepo
$ git sparse-checkout init --cone
$ git sparse-checkout set packages/api packages/shared
$ git checkout main

3. Habilita fsmonitor para status checks más rápidos. Git usa el file watcher del SO para detectar cambios:

$ git config core.fsmonitor true
$ git config core.untrackedcache true

4. Usa git gc para optimizar el tamaño del repositorio. Ejecuta periódicamente para comprimir objetos:

$ git gc --aggressive --prune=now

5. Usa git worktree para trabajo paralelo. Trabaja en múltiples ramas simultáneamente sin clonar:

$ git worktree add ../repo-hotfix main
$ cd ../repo-hotfix
# Ahora estás en main en un directorio separado
# Haz cambios de hotfix mientras tu rama de feature queda abierta en el original