Gitflow simplificado: el flujo que usan los equipos reales

Ya tienes todas las piezas: branches, merge, GitHub, PRs, conflictos. Ahora la pregunta es: ¿cómo se organiza todo esto en un equipo real? Porque sin un acuerdo de equipo, cada uno usa branches como quiere y el repo se convierte en un plato de espaguetis. Necesitas un "flujo" — un conjunto de reglas simples que todos siguen. El flujo que vamos a aprender es el mínimo viable para equipos de datos: simple, efectivo y sin burocracia innecesaria.

Existe un modelo llamado "Gitflow" (creado por Vincent Driessen en 2010) que propone branches como develop, release, hotfix, feature... Es completo pero DEMASIADO complejo para equipos pequeños o medianos. He visto equipos de 5 personas paralizados por seguir Gitflow al pie de la letra. Mi filosofía: empieza con lo mínimo que funcione y añade complejidad solo cuando la necesites. Para el 90% de equipos de datos, main + feature branches es todo lo que necesitas.

### El flujo mínimo viable: main + feature branches

El flujo más simple que funciona profesionalmente tiene estas reglas:

1. 01.main es sagrado: siempre funciona, siempre es deployable, nadie commitea directamente
2. 02.Cada tarea = una feature branch: por pequeña que sea, trabaja en una branch
3. 03.Nombres descriptivos: feature/, fix/, refactor/, docs/ + nombre claro
4. 04.Push frecuente: sube tu branch a GitHub al menos una vez al día (backup + visibilidad)
5. 05.PR obligatorio: todo cambio pasa por un Pull Request con al menos 1 revisión
6. 06.Merge via PR: nunca git merge local para meter cosas en main — siempre vía GitHub
7. 07.Borrar branch después del merge: no acumules branches muertas

### Un día típico con este flujo

Veamos cómo es un día de trabajo real usando este flujo. Imagina que eres ingeniero de datos en una fintech:

1# 09:00 - Llegas y actualizas main
2git switch main
3git pull
4
5# 09:05 - Tu tarea de hoy: añadir validación de transacciones
6git switch -c feature/validar-transacciones
7
8# 09:05 - 12:00 - Trabajas, haces varios commits
9git add .
10git commit -m "feat: función validar_monto()"
11# ... más trabajo ...
12git add .
13git commit -m "feat: función validar_fecha()"
14# ... más trabajo ...
15git add .
16git commit -m "test: tests para validación de transacciones"
17
18# 12:00 - Subes tu progreso (backup + visibilidad)
19git push -u origin feature/validar-transacciones
20
21# 14:00 - Terminas. Actualizas con main por si acaso.
22git switch main
23git pull
24git switch feature/validar-transacciones
25git merge main  # Resolver conflictos si los hay
26
27# 14:10 - Creas el PR
28gh pr create --title "feat: validación de transacciones" \
29  --body "Añade validar_monto() y validar_fecha()..."
30
31# 14:15 - Tu compañera María revisa, deja un comentario
32# Tú arreglas lo que pide:
33git add .
34git commit -m "refactor: renombrar según feedback de María"
35git push
36
37# 15:00 - María aprueba, tú mergeas desde GitHub
38# 15:01 - Borras la branch (GitHub te lo ofrece auto)
39
40# 15:05 - Siguiente tarea...
41git switch main
42git pull  # Trae tu merge
43git switch -c feature/siguiente-tarea

### Gitflow completo vs simplificado: cuándo complicarse

El Gitflow original de Vincent Driessen tiene más branches:

• ▹main: código en producción
• ▹develop: integración de features antes de release
• ▹feature/*: funcionalidades nuevas (salen de develop)
• ▹release/*: preparar una versión para producción
• ▹hotfix/*: fixes urgentes en producción

¿Cuándo necesitas este nivel de complejidad? Casi nunca en equipos de datos. Gitflow completo tiene sentido cuando: envías software empaquetado (como una app móvil con versiones), tienes un ciclo de releases planificado (v1.2, v1.3...), o tienes un equipo de QA que prueba releases antes del deploy. Para pipelines de datos, APIs internas o scripts de procesamiento, el flujo simplificado (main + feature branches + PRs) es todo lo que necesitas.

### Commit messages: el arte ignorado

Un buen flujo de Git también incluye buenos mensajes de commit. Si tus commits dicen "cambios", "fix", "wip", "asdf", tu historial es inútil. Cuando dentro de 3 meses necesites encontrar "ese commit donde cambiamos la lógica de descuentos", un buen mensaje te salva horas de investigación.

El estándar más usado es Conventional Commits. Es simple: un prefijo que dice qué tipo de cambio es, seguido de una descripción:

1# Conventional Commits:
2# tipo: descripción breve
3
4git commit -m "feat: añadir validación de emails"
5git commit -m "fix: manejar NULL en campo precio"
6git commit -m "refactor: simplificar función de limpieza"
7git commit -m "docs: documentar proceso de deploy"
8git commit -m "test: añadir tests para módulo de exportación"
9git commit -m "chore: actualizar dependencias"
10
11# Tipos comunes:
12# feat     = funcionalidad nueva
13# fix      = corrección de bug
14# refactor = cambio interno sin cambiar funcionalidad
15# docs     = documentación
16# test     = añadir o modificar tests
17# chore    = tareas de mantenimiento

### .gitignore: lo que nunca debe subir a GitHub

Todo flujo profesional necesita un buen .gitignore. Hay archivos que NUNCA deben subir al repo: credenciales, datos sensibles, archivos generados, cosas enormes. Un .gitignore para proyectos de datos en Python:

1# .gitignore para proyectos de datos
2
3# Entornos virtuales
4venv/
5.venv/
6env/
7
8# Variables de entorno (¡NUNCA subir credenciales!)
9.env
10.env.local
11*.secret
12
13# Datos (los datos no van en Git)
14data/
15*.csv
16*.parquet
17*.xlsx
18!data/.gitkeep
19
20# Python
21__pycache__/
22*.pyc
23*.pyo
24.pytest_cache/
25
26# Notebooks
27.ipynb_checkpoints/
28
29# IDE
30.vscode/
31.idea/
32
33# OS
34.DS_Store
35Thumbs.db