Cada rama, un propósito

Qué es una estrategia de ramas

Git permite crear las ramas que quieras, pero un equipo necesita reglas comunes: ¿desde dónde se empieza una tarea?, ¿qué rama está siempre lista para producción?, ¿cómo se arregla algo urgente sin arrastrar trabajo a medias? Una estrategia de ramas (branching strategy) responde eso. Las dos más conocidas son Gitflow y el desarrollo basado en el tronco (trunk-based).

Gitflow

Gitflow usa dos ramas permanentes y tres tipos de ramas temporales:

• main: solo contiene versiones publicadas; cada commit de main es algo que estuvo en producción, marcado con una etiqueta (v1.0, v1.1…).
• develop: donde se integra el trabajo terminado para la próxima versión.
• feature/nombre: sale de develop, contiene una funcionalidad y vuelve a develop.
• release/1.0: sale de develop cuando se congela la versión; ahí solo se corrigen detalles y se ajusta el número de versión. Se integra en main (con su etiqueta) y de regreso en develop.
• hotfix/1.0.1: sale de main para arreglar algo urgente en producción. Se integra en main (nueva etiqueta) y en develop, para que el arreglo no se pierda en la próxima versión.

Las integraciones se hacen con git merge --no-ff: aunque se pudiera avanzar rápido, se crea un commit de merge, y así queda visible en la historia qué commits formaron cada funcionalidad.

Trunk-based

En el desarrollo basado en el tronco hay una sola rama principal y todo el equipo integra en ella al menos una vez al día, con ramas que viven horas, no semanas. Lo que no está terminado se esconde detrás de un interruptor de funcionalidad (feature flag): el código ya está en main, pero apagado para los usuarios.

Funciona si hay pruebas automáticas que corren en cada cambio (el tema del módulo siguiente): sin ellas, integrar tan seguido rompe main a cada rato. A cambio, los conflictos son pequeños, porque nadie se aleja mucho de main, y se puede desplegar en cualquier momento. Gitflow encaja mejor con productos que publican versiones numeradas cada cierto tiempo y deben mantener varias a la vez; trunk-based, con servicios web que se despliegan continuamente.

Versionado semántico y mensajes de commit

Las etiquetas de versión suelen seguir el versionado semántico, MAYOR.MENOR.PARCHE: el parche sube cuando se corrige un error sin cambiar cómo se usa; la menor, cuando se agrega algo compatible con lo anterior; la mayor, cuando un cambio rompe la compatibilidad y quienes lo usan deben adaptarse. Al subir un número, los de su derecha vuelven a cero.

Muchos equipos escriben los mensajes con la convención Conventional Commits (fix: …, feat: …, feat!: … o un pie BREAKING CHANGE:), y una herramienta calcula la siguiente versión a partir de los mensajes.

git tag v1.0                 # etiqueta el commit actual
git tag                      # lista las etiquetas
git push origin v1.0         # las etiquetas se suben aparte (o git push --tags)

Antes de leer la respuesta