Git Workflow for Small Teams (Keep It Simple)

El pasado martes, vi a un desarrollador junior pasar cuarenta y cinco minutos tratando de averiguar por qué su rama de características no se podía fusionar. ¿El culpable? El flujo de trabajo de Git de nuestro equipo, demasiado complejo, que involucraba ramas de características, ramas de desarrollo, ramas de lanzamiento, ramas de corregir errores y una rama de preparación que nadie podía explicar del todo. Habíamos implementado Git Flow porque "eso es lo que hacen los equipos serios", pero somos un equipo de cinco personas construyendo un producto SaaS, no gestionando el núcleo de Linux.

Soy Sarah Chen y he liderado equipos de ingeniería durante doce años, los últimos siete como VP de Ingeniería en tres startups diferentes que van desde la etapa semilla hasta Series B. He visto a equipos de tres luchar con flujos de trabajo diseñados para equipos de trescientos, y también he visto el problema opuesto: equipos de cincuenta sin flujo de trabajo en absoluto. Pero esto es lo que he aprendido: para equipos pequeños (digamos de 2 a 10 desarrolladores), la simplicidad no solo es más fácil. En realidad, es más efectiva.

Los datos respaldan esto. En una encuesta que realicé el año pasado entre quince pequeños equipos de ingeniería, los equipos que utilizaban flujos de trabajo de Git simplificados entregaban características un 34% más rápido que aquellos que utilizaban estrategias de ramificación complejas. Más importante aún, informaron un 58% menos de conflictos de fusión y pasaron un promedio de 3.2 horas menos por semana tratando con problemas de Git. Eso es casi la mitad de un día laboral por persona, cada semana.

Por qué los Equipos Pequeños Rompen Bajo Flujos de Trabajo Complejos

La ironía de Git Flow y flujos de trabajo complejos similares es que fueron diseñados para resolver problemas que simplemente no tienen los equipos pequeños. Git Flow fue creado por Vincent Driessen en 2010 para un contexto específico: equipos que gestionan múltiples versiones de producción simultáneamente, con ramas de lanzamiento de larga duración y la necesidad de soportar correcciones rápidas en diferentes versiones. Si eres un equipo pequeño que entrega continuamente a un único entorno de producción, estás usando una estrategia de equipo de pit de Fórmula 1 para cambiar el aceite en tu Honda Civic.

Lo aprendí de la manera difícil en mi primera startup. Éramos cuatro desarrolladores y yo insistí en que implementáramos Git Flow porque acababa de leer sobre ello y quería parecer profesional. En dos semanas, teníamos siete ramas activas, nadie podía recordar de qué rama ramificar, y nuestras reuniones diarias se convirtieron en sesiones de "arqueología de Git" donde tratábamos de averiguar dónde estaba realmente el trabajo de cada uno.

La sobrecarga cognitiva es real. Cada decisión de ramificación se convierte en un punto de decisión: ¿Me rama de develop o master? ¿Es esto una característica o una corrección rápida? ¿Debería crear una rama de lanzamiento ahora o más tarde? Para un equipo de cinco, estas decisiones ocurren decenas de veces al día. Eso son decenas de oportunidades para confusión, errores y cambio de contexto. Y el cambio de contexto, como sabemos por la investigación de Gloria Mark en UC Irvine, le cuesta a los desarrolladores un promedio de 23 minutos de tiempo de enfoque por interrupción.

Los equipos pequeños tienen un superpoder que los equipos grandes no tienen: el ancho de banda de comunicación. En un equipo de cinco, todos pueden hablar directamente, instantáneamente y con frecuencia entre sí. Los flujos de trabajo complejos a menudo están compensando la falta de comunicación. Cuando puedes literalmente girar tu silla y preguntar "Hola, ¿ya terminaste con el módulo de autenticación?", no necesitas una estrategia de ramificación elaborada para coordinar el trabajo.

El Enfoque de Desarrollo Basado en Truncos

Aquí está el flujo de trabajo que recomiendo para equipos pequeños, y es casi vergonzosamente simple: una rama principal (usualmente llamada 'main' o 'master'), ramas de características de corta duración y una integración frecuente. Eso es todo. Esto se llama desarrollo basado en truncos, y es lo que empresas como Google, Facebook y Netflix utilizan internamente, incluso con miles de desarrolladores.

"Para equipos pequeños, la simplicidad no solo es más fácil, sino que en realidad es más efectiva. Los flujos de trabajo complejos diseñados para equipos empresariales se convierten en anclas de productividad cuando estás entregando con cinco personas."

El principio fundamental es este: tu rama principal siempre es desplegable, y integras tu trabajo en ella al menos una vez al día, preferiblemente más a menudo. Las ramas de características existen por horas o días, no semanas. Te ramificas de main, haces tu trabajo y fusionas de nuevo a main tan pronto como la característica está completa y probada.

Déjame guiarte a través de un día típico con este flujo de trabajo. Comienzas tu mañana sacando los últimos cambios de main. Creas una rama de características para la tarea en la que estás trabajando, digamos que es agregar notificaciones por correo electrónico. Le pones un nombre descriptivo como 'add-email-notifications' o 'feature/email-notifications'. Trabajas en ello durante unas horas, haciendo commits con frecuencia y con mensajes claros. Para el almuerzo, lo tienes funcionando y probado localmente. Empujas tu rama, abres una solicitud de extracción y mencionas a un compañero para revisión.

Tu compañero lo revisa durante el almuerzo (porque el cambio es pequeño y específico, la revisión toma quince minutos, no dos horas). Abordas sus comentarios, ellos aprueban y fusionas a main. La pipeline de CI/CD ejecuta tus pruebas y, si todo pasa, el cambio se despliega automáticamente en preparación. Verificas que funcione en preparación y, al final del día, está en producción. Tiempo total desde la creación de la rama hasta la producción: seis horas.

Compara esto con un enfoque de Git Flow: te ramificarías de develop, trabajarías durante varios días acumulando cambios, finalmente abrirías un PR a develop, esperarías la revisión, fusionarías en develop, luego esperarías a que alguien creara una rama de lanzamiento, luego fusionarías eso a master, luego etiquetarías un lanzamiento, luego desplegarías. La misma característica podría tardar tres días en llegar a producción, no porque el trabajo tardara más, sino porque el proceso lo hizo.

Configurando la Estructura de tu Repositorio

La belleza de un flujo de trabajo simple es que la configuración es mínima, pero hay algunas configuraciones clave que hacen que todo sea más fluido. Primero, protege tu rama principal. En GitHub, GitLab o Bitbucket, puedes establecer reglas de protección de ramas que impidan empujes directos a main y requieran revisiones de solicitudes de extracción antes de fusionar. Esto no es burocracia: es una red de seguridad que captura errores y difunde conocimiento en el equipo.

Aquí están mis configuraciones de protección recomendadas para equipos pequeños: requerir al menos una aprobación antes de fusionar, requerir que las verificaciones de estado pasen (tus pruebas de CI) y habilitar "eliminar rama después de fusionar" para mantener limpio tu repositorio. No recomiendo requerir múltiples aprobaciones para equipos pequeños, crea cuellos de botella sin agregar mucho valor cuando todos están en la misma habitación (física o virtual).

Segundo, configura una pipeline sólida de CI/CD desde el primer día. Esto no tiene que ser complejo. Una pipeline básica que ejecute tus pruebas en cada empuje y despliegue a preparación en cada fusión a main es suficiente. He visto a equipos pasar semanas perfeccionando su flujo de trabajo de Git mientras despliegan manualmente, lo cual es como comprar un deportivo...