Git para equipos pequeños: flujo de trabajo sin dramas

La mayoría de guías sobre Git están escritas para equipos de 50 personas. Hablan de Git Flow, ramas de release, hotfix branches y diagramas que necesitan media hora para entenderse. Si tu equipo tiene entre 2 y 5 desarrolladores, todo eso es ruido. Lo que necesitas es un flujo simple, predecible y que no genere conflictos cada vez que alguien hace push.

Llevo años montando flujos de trabajo para equipos pequeños y la conclusión siempre es la misma: menos reglas, mejor ejecutadas, ganan a procesos complejos que nadie sigue.

El problema real: no es Git, es la falta de acuerdo

Git es una herramienta. Los conflictos, los merges rotos y las ramas abandonadas no son culpa de Git. Son culpa de que el equipo no tiene reglas claras sobre cómo usarlo.

Cuando un equipo pequeño no define su flujo de trabajo, pasan cosas como estas:

• Dos personas trabajan en el mismo archivo sin saberlo durante días.
• Ramas con nombres como fix, test2, nueva-version-final-v3 que nadie sabe qué contienen.
• Merges a main sin revisión que rompen producción un viernes a las 18:00.
• Un desarrollador lleva dos semanas en una rama que ya es imposible de fusionar.

La solución no es más herramientas. Es un acuerdo de equipo que quepa en media página.

El flujo que funciona: trunk-based simplificado

Para equipos de 2 a 5 personas, recomiendo un flujo basado en una rama principal (main) con ramas de corta duración. Sin ramas de develop, sin ramas de release, sin staging branches.

Las reglas son cinco

1. main siempre funciona. Nadie hace push directo a main. Todo entra por pull request.
2. Las ramas viven como máximo 2-3 días. Si una tarea necesita más, se divide en tareas más pequeñas.
3. Nombres de rama descriptivos y consistentes. Siempre con el mismo formato.
4. Toda rama pasa por pull request con al menos una revisión.
5. Se hace merge y se borra la rama. Nada de acumular ramas muertas.

Cinco reglas. Fáciles de recordar, fáciles de cumplir.

Nombres de rama: el detalle que marca la diferencia

Un buen nombre de rama te dice qué se está haciendo sin tener que abrir el código. Mi convención preferida:

tipo/descripcion-corta

Ejemplos concretos:

• feat/formulario-contacto
• fix/error-login-movil
• refactor/extraer-servicio-pagos
• docs/actualizar-readme-api

Los tipos que uso son cuatro: feat (nueva funcionalidad), fix (corrección de bug), refactor (mejora interna sin cambio funcional) y docs (documentación). No necesitas más. Si alguien propone añadir chore, style, perf y otros diez tipos, está complicando algo que debería ser simple.

Lo que hay que evitar

• Nombres genéricos: update, cambios, test.
• Nombres con fecha: fix-14-marzo. No aportan contexto.
• Nombres personales: rama-de-pedro. Si Pedro se va de vacaciones, nadie sabe qué contiene.

Pull requests: revisiones que aportan valor

En un equipo de 3 personas, la tentación de saltarse las revisiones es enorme. “Ya lo miro yo, que es un cambio pequeño.” Ese cambio pequeño es el que rompe producción.

Las pull requests en equipos pequeños no necesitan ser exhaustivas. No estás auditando código — estás verificando que el cambio tiene sentido y no introduce errores obvios.

Qué revisar en menos de 10 minutos

• El PR tiene descripción. No hace falta un ensayo. Dos líneas explicando qué hace y por qué.
• Los nombres son claros. Variables, funciones, archivos. Si necesitas preguntar qué hace algo, el nombre es malo.
• No hay código comentado ni console.log perdidos.
• Los tests pasan. Si los hay. Si no los hay, plantéate si deberían existir.
• El cambio es coherente. Un PR que arregla un bug, refactoriza una clase y añade una funcionalidad nueva son tres PRs, no uno.

Esto conecta directamente con tener tests automatizados que validen los cambios antes de mergearse. Una buena suite de tests reduce la carga de la revisión manual y previene que tu código funcione en local pero falle en producción.

Evitar conflictos: la estrategia preventiva

Los conflictos de merge no se resuelven — se previenen. La mayoría nacen de ramas que viven demasiado tiempo o de equipos que no se comunican.

Tres hábitos que eliminan el 90 % de conflictos

1. Ramas cortas. Una rama que dura un día rara vez tiene conflictos. Una que dura dos semanas los tiene casi siempre. Si tu tarea es grande, divídela. Es mejor hacer tres PRs pequeños que uno gigante.

2. Rebase diario. Cada mañana, antes de empezar a trabajar:

git fetch origin
git rebase origin/main

Esto incorpora los cambios que otros han fusionado a main mientras trabajabas. Si hay un conflicto, será pequeño y reciente, fácil de resolver. Si esperas a resolver conflictos acumulados de una semana, será un infierno.

3. Comunicación directa. Si dos personas van a tocar el mismo archivo, se avisan. No hace falta una herramienta — un mensaje en el canal del equipo basta. Igual que con una buena estrategia de caché donde la coordinación evita problemas de invalidación, en Git la comunicación evita problemas de conflictos.

Commits: mensajes que cuentan una historia

Un historial de commits bien escrito es documentación gratis. Un historial de “fix”, “changes”, “wip” es ruido que ocupa espacio.

La estructura que recomiendo:

tipo: descripción breve en imperativo

Contexto adicional si es necesario.

Buenos ejemplos:

• feat: añadir validación de email en formulario de contacto
• fix: corregir cálculo de IVA en pedidos con descuento
• refactor: extraer lógica de autenticación a servicio independiente

Malos ejemplos:

• cambios
• arreglo cosa
• wip no tocar

Un commit, un cambio lógico

No mezcles en el mismo commit un fix de CSS con una migración de base de datos. Si necesitas revertir uno, vas a tener que revertir ambos. Cada commit debería poder revertirse de forma independiente sin romper nada.

Proteger la rama principal

Incluso en equipos de dos personas, proteger main merece la pena. La configuración mínima en GitHub o GitLab:

• Prohibir push directo a main. Todo entra por PR.
• Requerir al menos una aprobación. En un equipo de dos, significa que el otro lo revisa.
• Pasar CI antes de mergear. Aunque sea solo ejecutar los tests y un linter.

Esto aplica el mismo principio que tener backups automáticos bien configurados: las protecciones automáticas te salvan de errores humanos a las 18:00 de un viernes.

Si quieres llevar la calidad de tu código un paso más allá, combina este flujo con una estrategia de desarrollo a medida vs WordPress que permita escalabilidad sin sacrificar control.

Cuándo este flujo no es suficiente

Este flujo funciona para la mayoría de proyectos con equipos pequeños. Pero si tu proyecto tiene releases programados con múltiples versiones en producción simultáneamente, o si necesitas mantener ramas de soporte a largo plazo, necesitarás algo más estructurado.

Para el 90 % de los proyectos de freelancers y pymes — una aplicación web, un e-commerce, un SaaS — trunk-based simplificado es más que suficiente.

Implementarlo no cuesta nada, no implementarlo sí

Definir un flujo de Git lleva una reunión de 30 minutos. No hacerlo cuesta horas de conflictos, bugs en producción y frustración acumulada.

Si tu equipo necesita ayuda para establecer buenas prácticas de desarrollo, desde flujos de Git hasta CI/CD y despliegues, puedo ayudaros. Y si tienes dudas concretas sobre tu caso, escríbeme.