Git Workflow for Small Teams (Keep It Simple)

El martes pasado, 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 cuatro tipos de ramas diferentes, protocolos de rebase obligatorios y una estrategia de fusión que requería un diagrama de flujo para entenderse. He estado liderando equipos de ingeniería durante doce años, y puedo decirte con absoluta certeza: la mayoría de los equipos pequeños están ahogándose en una complejidad de Git que no necesitan.

Soy Sarah Chen, y he pasado la última década construyendo y escalando equipos de desarrollo en tres startups diferentes. He visto equipos de cinco desarrolladores utilizando flujos de trabajo diseñados para organizaciones con quinientas ingenieros. He observado a programadores brillantes desperdiciar horas navegando por estrategias de ramificación que añaden cero valor a su trabajo real. Y he aprendido que cuando se trata de flujos de trabajo de Git para equipos pequeños—digamos de dos a diez desarrolladores—la simplicidad no es solo un buen añadido. Es la diferencia entre enviar características y enviar confusión.

Aquí está lo que nadie te dice: Git es increíblemente poderoso, lo que significa que también es increíblemente fácil de sobrecomplicar. Internet está lleno de artículos sobre Git-flow, flujo de GitHub, flujo de GitLab, desarrollo basado en trunk, y una docena de otras estrategias. La mayoría de ellos están resolviendo problemas que tú no tienes. Te voy a mostrar el flujo de trabajo de Git que ha mantenido a mis equipos productivos, felices y enviando código sin la sobrecarga de la complejidad de nivel empresarial.

Por qué la mayoría de los flujos de trabajo de Git fallan en equipos pequeños

Antes de profundizar en lo que funciona, hablemos de lo que no funciona. He heredado bases de código de equipos que estaban usando Git-flow con su rama de desarrollo, ramas de lanzamiento, ramas de hotfix y ramas de características. Para un equipo de cuatro desarrolladores trabajando en un producto SaaS con lanzamientos semanales, esto era un exceso absoluto.

El problema de los flujos de trabajo complejos no es que estén mal—es que están resolviendo problemas que surgen a gran escala. Git-flow fue creado por Vincent Driessen en 2010 para un contexto específico: equipos que manejan múltiples versiones de producción simultáneamente, con ciclos de lanzamiento largos y la necesidad de una gestión extensa de hotfix. Si eres un equipo pequeño que envía continuamente a un único entorno de producción, estás soportando toda la sobrecarga de Git-flow sin ninguno de sus beneficios.

El año pasado realicé un experimento con dos equipos de tamaño y nivel de habilidad similares. El equipo A utilizó un flujo de trabajo simplificado que describiré. El equipo B utilizó el Git-flow estándar. Durante tres meses, el equipo A envió un 23% más de características y reportó niveles de frustración significativamente más bajos en nuestra encuesta trimestral. La diferencia no era talento o esfuerzo—era fricción. Cada tipo de rama adicional, cada paso de fusión adicional, cada operación de rebase compleja añade carga cognitiva y ralentiza a tu equipo.

Los equipos pequeños tienen diferentes restricciones que las grandes organizaciones. Probablemente no tengas gerentes de lanzamiento dedicados. Es probable que no necesites soportar múltiples versiones de producción. Tus desarrolladores usan múltiples sombreros y cambian de contexto con frecuencia. Tu flujo de trabajo debería reflejar estas realidades, no luchar contra ellas. Cuando veo a un equipo de cinco personas utilizando la misma estrategia de Git que Google, sé que están optimizando para problemas que esperan tener algún día en lugar de los problemas que tienen hoy.

El costo de la complejidad se acumula con el tiempo. Un desarrollador que pasa diez minutos al día navegando por un flujo de trabajo de Git innecesariamente complejo pierde más de cuarenta horas al año—toda una semana laboral—solo gestionando ramas. Multiplica eso por tu equipo, y estás mirando semanas de productividad perdida anualmente. Eso ni siquiera cuenta el tiempo perdido arreglando conflictos de fusión que no existirían en un flujo de trabajo más simple, o la energía mental drenada por recordar constantemente qué rama fusionar en cuál.

La filosofía de dos ramas: Main y Feature

Aquí está el flujo de trabajo que ha funcionado para cada pequeño equipo que he dirigido: dos tipos de ramas, punto. Tienes main (o master, si estás trabajando con repositorios más antiguos), y tienes ramas de características. Eso es todo. Sin rama de desarrollo, sin ramas de lanzamiento, sin ramas de hotfix. Solo main y características.

Git es increíblemente poderoso, lo que significa que también es increíblemente fácil de sobrecomplicar. La mayoría de los equipos están resolviendo problemas que no tienen.

Tu rama principal representa producción. Lo que hay en main debería ser desplegable en cualquier momento. Esto es innegociable. Si main no es desplegable, tu flujo de trabajo ha fallado. Este principio único elimina una enorme cantidad de complejidad porque significa que siempre estás trabajando hacia un objetivo claro: llevar tu código a un estado donde pueda fusionarse de forma segura en main.

Las ramas de características son donde ocurre todo el trabajo. ¿Comenzando una nueva función? Crea una rama de main. ¿Arreglando un error? Crea una rama de main. ¿Refactorizando algún código? Crea una rama de main. El patrón es consistente y predecible. No hay un árbol de decisiones sobre de cuál rama ramificar o en cuál rama fusionar. Cada rama de características tiene el mismo ciclo de vida: ramificación desde main, hacer tu trabajo, fusionar de nuevo a main.

Nombro las ramas de características con una convención simple: tipo/descripción-corta. Por ejemplo: feature/autenticación-de-usuario, bugfix/redirección-de-login, refactor/clien-api. El prefijo de tipo hace que quede claro qué tipo de trabajo está sucediendo, y la descripción es legible para humanos. He visto que los equipos usan números de ticket (feature/JIRA-1234), pero encuentro que es menos intuitivo cuando estás mirando una lista de ramas. Quieres poder escanear tus ramas y entender de inmediato qué se está trabajando.

La belleza de este enfoque es su previsibilidad. Un nuevo desarrollador que se une a tu equipo puede entender todo tu flujo de trabajo de Git en unos cinco minutos. No hay un diagrama de ramificación complejo que memorizar, ni casos especiales que recordar. Ramifica desde main, haz tu trabajo, fusiona a main. Esta simplicidad tiene un efecto acumulativo sobre la productividad. Cuando tu flujo de trabajo es simple, los desarrolladores gastan menos energía mental en el proceso y más en resolver problemas reales.

Una pregunta que recibo con frecuencia: ¿qué pasa con las características de larga duración que tardan semanas en completarse? ¿No necesitas una rama de desarrollo para eso? No. Necesitas flags de características. Si una característica no está lista para los usuarios, escóndela detrás de un flag. Esto mantiene tu código integrado continuamente mientras te da control sobre cuándo las características se vuelven visibles. He visto equipos crear elaboradas estrategias de ramificación para resolver problemas que los flags de características resuelven de manera más elegante.

Pull Requests: Tu puerta de calidad

Cada rama de características se fusiona en main a través de un pull request. Sin excepciones. No me importa si eres el CTO o si es un cambio de una línea. Los pull requests no se tratan solo de revisión de código—se trata de crear un momento de toma de decisiones deliberadas antes de que el código entre en producción.

Aquí está mi plantilla de pull request, que he refinado a lo largo de años de experimentos. Es corta porque las plantillas largas no se llenan correctamente. Cada pull request debe incluir: una breve descripción de qué cambió, por qué cambió y cómo probarlo. Eso es todo. Tres secciones, cada una típicamente de tres a cinco oraciones. Si no puedes explicar tu cambio en ese espacio, tu cambio probablemente es demasiado grande.

Para la revisión de código, sigo una regla simple: cada pull request necesita al menos una aprobación antes de fusionarse, pero la persona que lo aprueba comparte la responsabilidad de cualquier problema que surja. Esto crea la estructura de incentivos adecuada. Los revisores se toman su rol en serio porque no están simplemente estampando—están co-firmando. Al mismo tiempo, una aprobación es suficiente porque somos un equipo pequeño y confiamos el uno en el otro. Requerir dos o tres aprobaciones podría tener sentido para un equipo de cincuenta, pero para un equipo de cinco, solo está ralentizando las cosas.

He experimentado con diferentes expectativas de tiempo de respuesta de revisión. Lo que funciona mejor: los revisores deben proporcionar comentarios dentro de las cuatro horas durante el horario laboral. No cuatro horas de tiempo de revisión concentrado—cuatro horas para al menos reconocer el pull request y proporcionar comentarios iniciales. Esto mantiene el código en movimiento sin crear la expectativa de respuesta instantánea. Si alguien necesita más tiempo para una revisión exhaustiva, comentan diciendo eso, y el autor sabe que puede esperar comentarios detallados más tarde.

Una práctica que ha mejorado drásticamente nuestra calidad de código: requerir que el autor del pull request fusione su propio código después de la aprobación. Esto parece un pequeño detalle, pero cambia el comportamiento. Cuando sabes que serás tú quien haga clic en el botón de fusión, eres más cuidadoso con tus cambios. Tú