Gitflow simplificado para equipos de analítica

En 2005, Linus Torvalds escribió Git en diez días porque el kernel de Linux lo estaban tocando cientos de programadores a la vez, repartidos por todo el mundo, y no había manera de que ninguno pisara el trabajo de otro. La Linux Foundation contó tres años después que esa cifra se había triplicado desde entonces, hasta rozar el millar por versión. Ese mismo problema aparece cada mañana en los equipos de analítica, y ahí no hacen falta cientos de personas: bastan tres. María actualiza la query del informe semanal, Javi reescribe el cálculo de retención y tú añades un gráfico nuevo al notebook de KPIs. Si los tres tocáis el mismo fichero sin coordinaros, alguien va a perder su trabajo. Git resolvió eso para el kernel de Linux. Hoy lo vas a usar para resolver exactamente lo mismo en un equipo mucho más pequeño.

Ya sabes hacer commits, crear branches y subir tu código a GitHub. Ahora la pregunta es: ¿cómo se organiza todo esto cuando hay varias personas tocando el mismo repositorio? Sin un acuerdo de equipo, cada uno crea branches con nombres distintos, fusiona cuando quiere, y el repo se convierte en un plato de espaguetis donde nadie sabe qué versión es la buena. Necesitas un flujo — un conjunto de reglas simples que todos siguen.

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

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. He visto equipos de 5 analistas paralizados por seguir Gitflow al pie de la letra: nadie se atrevía a fusionar nada porque no sabían si había que pasar por develop o por release. Mi consejo después de doce años trabajando con datos: empieza con lo mínimo que funcione y añade complejidad solo cuando la necesites. En los equipos de analítica que me he encontrado, main + feature branches ha bastado casi siempre. Y si algún día te hace falta más, lo vas a notar tú antes de que nadie te lo diga: hasta entonces, no lo añadas.

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

1. 01.main es sagrado: siempre funciona, siempre es la versión publicada, 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/, docs/ + nombre claro de lo que haces
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 vía 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

### Qué significa "main es la versión que funciona"

En un equipo de ingeniería de software, "main es deployable" significa que el código se puede poner en producción en cualquier momento. Para un equipo de analítica, el concepto es ligeramente distinto pero igual de importante: main es la versión que funciona. Es decir: si tu equipo tiene un informe automatizado que se ejecuta cada lunes a las 7:00, ese informe lee los scripts que están en main. Si alguien rompe main un domingo por la noche, el lunes el informe sale mal — o peor, no sale.

Piensa en main como la estantería de una biblioteca: los libros que están ahí son los que cualquiera puede coger y usar. Si estás escribiendo un capítulo nuevo, no lo pones en la estantería a medias — trabajas en tu borrador (tu branch), y cuando está listo y revisado, lo colocas. Ese es el trato con main: solo llegan cosas terminadas y revisadas.

En la práctica, para un equipo de analistas esto significa:

• ▹Las queries que alimentan dashboards están en main y funcionan
• ▹Los scripts de informes periódicos leen de main
• ▹El diccionario de métricas en main es la versión oficial
• ▹Cualquier compañero puede clonar main y ejecutar los análisis sin que nada falle

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

Veamos cómo es un día de trabajo real usando este flujo. Eres analista en un e-commerce y tu tarea del día es crear una query nueva que calcule la retención por cohorte (grupo de usuarios que se registraron el mismo mes) para que la directora de producto pueda ver si el rediseño de la app está funcionando:

1# 09:00 - Llegas y actualizas main
2git switch main
3git pull
4
5# 09:05 - Tu tarea de hoy: query de retencion por cohorte
6git switch -c feature/query-retencion-cohortes
7
8# 09:05 - 12:00 - Trabajas en tu query, haces varios commits
9git add queries/retencion_cohortes.sql
10git commit -m "feat: query base de retencion mensual"
11# ... mas trabajo ...
12git add queries/retencion_cohortes.sql
13git commit -m "feat: anadir filtro por canal de adquisicion"
14
15# 12:00 - Subes tu progreso (backup + visibilidad)
16git push -u origin feature/query-retencion-cohortes
17
18# 14:00 - Terminas. Actualizas con main por si acaso.
19git switch main
20git pull
21git switch feature/query-retencion-cohortes
22git merge main  # Resolver conflictos si los hay
23
24# 14:10 - Creas el PR
25gh pr create --title "feat: retencion por cohorte para producto" \
26  --body "Query que calcula retencion M1-M6 por cohorte mensual."
27
28# 14:30 - Tu companero Carlos revisa, sugiere anadir un comentario
29# Tu arreglas lo que pide:
30git add queries/retencion_cohortes.sql
31git commit -m "docs: anadir comentario explicativo al CTE"
32git push
33
34# 15:00 - Carlos aprueba, tu mergeas desde GitHub
35# 15:01 - Borras la branch (GitHub te lo ofrece automaticamente)
36
37# 15:05 - Siguiente tarea...
38git switch main
39git pull
40git switch -c fix/informe-semanal-duplicados

### Nombres de branches: el convenio que comunica intención

Un nombre de branch no es un capricho estético. Es comunicación con tu equipo. Cuando ves feature/query-retencion-marketing en la lista de branches, sabes tres cosas sin abrir ningún fichero: es funcionalidad nueva (feature), tiene que ver con retención, y es para el equipo de marketing. Eso es información gratis que ahorra preguntas en el chat.

El convenio que usan la mayoría de equipos profesionales:

• ▹feature/ — funcionalidad nueva: un análisis, una query, un notebook
• ▹fix/ — corrección de algo que está mal: un cálculo erróneo, un duplicado, un filtro roto
• ▹docs/ — documentación: diccionario de métricas, README, comentarios en queries
• ▹refactor/ — reorganizar sin cambiar resultados: renombrar columnas, limpiar un notebook

Ejemplos reales en un equipo de analítica:

1# Analisis nuevos
2feature/query-retencion-marketing
3feature/cohortes-producto-q3
4feature/segmentacion-clientes-rfm
5
6# Correcciones
7fix/informe-semanal-duplicados
8fix/calculo-churn-sin-trials
9fix/filtro-fecha-kpis-diarios
10
11# Documentacion
12docs/diccionario-metricas
13docs/readme-estructura-repo
14docs/comentarios-query-ingresos
15
16# Reorganizacion
17refactor/renombrar-columnas-legacy
18refactor/separar-queries-por-area

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

El Gitflow original de Driessen tiene más branches: develop (integración antes de publicar), release (preparar una versión), hotfix (arreglos urgentes en producción). Tiene sentido cuando envías software empaquetado con versiones (una app móvil con v1.2, v1.3...) o tienes un equipo de QA que prueba releases antes del despliegue.

Para un equipo de analítica que mantiene queries, notebooks e informes, esa complejidad no aporta nada. No envías una "versión 2.3 del informe de KPIs" — simplemente actualizas la query y el próximo lunes el informe sale con los datos correctos. El flujo simplificado (main + feature branches + PRs) cubre de sobra esa realidad.

### Commit messages: el arte ignorado

Un buen flujo de Git incluye buenos mensajes de commit. Si tus commits dicen "cambios", "fix", "wip", "asdf", tu historial es inútil. Cuando dentro de 3 meses la directora de marketing te pregunte "cuándo cambiamos el cálculo de atribución?", un buen mensaje te salva horas de investigación. El estándar más usado es Conventional Commits: un prefijo que dice qué tipo de cambio es, seguido de una descripción breve:

1# Conventional Commits para analitica:
2
3git commit -m "feat: query de retencion por cohorte mensual"
4git commit -m "fix: corregir duplicados en informe semanal"
5git commit -m "refactor: simplificar CTE de ingresos recurrentes"
6git commit -m "docs: documentar metrica de churn en diccionario"
7git commit -m "feat: anadir grafico de conversion al notebook"
8git commit -m "fix: filtro de fecha excluia el ultimo dia del mes"
9
10# Tipos comunes en analitica:
11# feat     = analisis nuevo, query nueva, grafico nuevo
12# fix      = correccion de calculo, filtro, duplicado
13# refactor = reorganizar sin cambiar resultados
14# docs     = documentacion, comentarios, diccionario

### .gitignore para un repo de analítica

Todo flujo profesional necesita un buen .gitignore (el fichero que le dice a Git qué cosas NO debe rastrear). En un repo de analítica, hay cosas que nunca deben subir: los datos en bruto (pesan demasiado y cambian cada día), las credenciales de la base de datos, y los ficheros temporales que genera tu ordenador (computadora). Un .gitignore típico para un equipo de analistas:

1# .gitignore para un repo de analitica
2
3# Variables de entorno (credenciales de bases de datos)
4.env
5.env.local
6
7# Datos locales (no van en Git: pesan y cambian)
8*.csv
9*.xlsx
10*.parquet
11datos/*
12!datos/.gitkeep
13
14# Python
15__pycache__/
16*.pyc
17.venv/
18venv/
19
20# Notebooks: los checkpoints son cache, no codigo
21.ipynb_checkpoints/
22
23# IDE y sistema
24.vscode/
25.idea/
26.DS_Store
27Thumbs.db

### El repo típico de un equipo de analítica

Un equipo de ingeniería de software tiene carpetas como src/, tests/, deploy/. Un equipo de analítica tiene otra estructura, porque su trabajo es diferente. Así suele verse un repo de analítica bien organizado:

1analitica-ecommerce/
2  queries/                  # Queries SQL organizadas por area
3    retencion/
4      cohortes_mensual.sql
5      churn_por_segmento.sql
6    ingresos/
7      ingresos_recurrentes.sql
8      arpu_por_plan.sql
9    marketing/
10      atribucion_canal.sql
11      cac_por_campana.sql
12  informes/                 # Scripts que generan informes periodicos
13    kpis_semanales.py
14    informe_mensual.py
15  notebooks/                # Analisis exploratorios
16    exploracion_churn_q3.ipynb
17    segmentacion_rfm.ipynb
18  docs/                     # Documentacion del equipo
19    diccionario_metricas.md
20    guia_nuevos_analistas.md
21  .gitignore
22  README.md

### Cuando "publicar" no es deploy: el ciclo del analista

En ingeniería de software, fusionar a main dispara un "deploy" — el código se sube a un servidor y los usuarios lo ven. Para un equipo de analítica, fusionar a main tiene un efecto diferente pero igualmente real: el próximo informe automatizado usará esa versión. Si tu equipo tiene un script que cada lunes ejecuta queries/kpis_semanales.sql y envía los resultados por email al equipo directivo, lo que está en main el lunes a las 7:00 es lo que la dirección ve a las 7:05.

Esa es la razón de que main sea sagrado. No es burocracia: es que lo que fusionas a main tiene consecuencias reales. Si corriges el cálculo del churn (tasa de bajas) en tu branch y lo fusionas a main el viernes, el informe del lunes mostrará el número nuevo. Si ese número nuevo está mal porque no lo revisó nadie, la directora de producto tomará una decisión equivocada basándose en tu error. El PR con revisión no es un trámite: es la red de seguridad que evita que un error tuyo se convierta en una decisión equivocada de negocio.

### Errores comunes y cómo evitarlos

• ▹"Solo es un cambio pequeño, lo commiteo directo a main" — No. Un typo en un WHERE puede filtrar la mitad de los datos sin que nadie lo note durante semanas.
• ▹"Trabajo solo, no necesito branches" — Aunque trabajes solo, las branches son tu historial de decisiones. Dentro de 3 meses agradecerás poder hacer git log y ver que cada cambio tiene un por qué.
• ▹"No me acuerdo de qué era esta branch, así que creo otra" — Borra la vieja primero. Un repositorio con 30 branches abandonadas es como un escritorio lleno de papeles: no encuentras nada.
• ▹"El PR es un trámite, me lo apruebo yo mismo" — Pierde todo su valor. El PR existe para que otro par de ojos vea algo que tú no ves. Aunque sea un revistazo de 2 minutos, ese revistazo caza errores.

### Resumen del flujo

El flujo simplificado para un equipo de analítica cabe en una servilleta: main es la versión que funciona y nadie la toca directamente. Cada tarea se hace en una branch con nombre descriptivo. Cuando terminas, abres un PR para que alguien revise. Si está bien, se fusiona a main y se borra la branch. El próximo informe automatizado usará la nueva versión. Eso es todo. Siete reglas, un diagrama, y un equipo que trabaja sin pisarse.

Ya sabes organizar el trabajo en equipo. Ahora falta ponerlo en práctica de verdad: crear un repo, simular varios analistas trabajando en paralelo, resolver un conflicto y ver el resultado limpio en el historial. Eso es exactamente lo que harás en el siguiente proyecto.