Git y control de versiones en equipo

Casi ningún equipo tiene un problema con Git como herramienta. El problema es la ausencia de acuerdo: cada persona ramifica a su manera, las revisiones dependen de quién esté de guardia y nadie sabe con seguridad qué hay en producción. Esta guía recoge las decisiones que conviene cerrar y por qué.

Elegir un modelo de ramas

Hay dos familias razonables y una que casi siempre sobra. Trunk-based: todo el mundo integra en main varias veces al día, detrás de *feature flags* si hace falta, y se publica desde ahí. GitFlow: ramas de larga vida (develop, release/*, hotfix/*) con un ritual de promoción entre ellas.

• Equipo pequeño (2–8) que despliega a menudo: trunk-based con ramas de vida corta (horas o un par de días).
• Producto con versiones numeradas, varias soportadas a la vez, o certificaciones por versión: GitFlow o una variante.
• La rama que vive semanas sin integrarse no es una estrategia, es deuda: el *merge* será caro y arriesgado.

Pull requests que sirven para algo

Una *pull request* es una unidad de revisión, no un volcado de dos semanas de trabajo. Cuanto más pequeña, más honesta es la revisión: por encima de 400 líneas, quien revisa aprueba por cansancio.

1. Un cambio por PR, con una descripción de qué problema resuelve y cómo probarlo.
2. La rama parte de main actualizado y se reintegra en cuestión de días, no de semanas.
3. La CI (tests, lint, build) pasa antes de pedir revisión humana, no después.
4. Al menos una aprobación de alguien que no sea el autor, y que esa persona pueda de verdad decir que no.

Revisión de código: qué mirar

La revisión no es un control de estilo —eso lo hace un *linter* automático—. Es una conversación sobre si el cambio es correcto, si es la solución más simple y si alguien más podrá mantenerlo. Comentar el nombre de una variable mientras se cuela un problema de concurrencia es perder el tiempo de todos.

Versionado y publicaciones

Etiqueta cada publicación (git tag) con versionado semántico y un registro de cambios generado a partir de los mensajes de *commit*. Así, cuando algo se rompe en producción, la pregunta «¿qué entró en esta versión?» se responde en diez segundos y no reconstruyendo el historial a mano.