Qué construimos con él
Git no es una preferencia, es el sustrato. Pero cómo lo usa un equipo sí es una decisión real, y se nota en lo fácil que resulta trabajar sobre una base de código un año después.
Nuestro planteamiento por defecto son ramas de vida corta que salen de un tronco que siempre compila, una pull request revisada por cambio y CI ejecutando tests, lint y una build en cada push. Los commits se escriben para leerse: un mensaje que explica por qué, no una reformulación del diff.
Dónde encaja
En todos los encargos, incluido el trabajo dentro del propio repositorio de un cliente. Cuando nos incorporamos a un equipo existente mediante ampliación de equipo, adoptamos su modelo de ramas y sus convenciones de revisión en lugar de importar los nuestros: la coherencia dentro de un repositorio vale más que el que un flujo concreto sea objetivamente mejor.
Cuándo lo recomendamos
Para el flujo de arriba: desarrollo basado en tronco con ramas pequeñas y fusionadas a menudo. Las ramas de funcionalidad de vida larga son de donde salen el dolor de las fusiones y el código obsoleto, y el coste aterriza semanas después de la decisión que lo causó.
Donde discutimos es en el proceso por el proceso: squash obligatorio, formatos rígidos de mensaje de commit o un modelo de ramas con cinco ramas permanentes en un equipo de tres. La gracia es tener un historial que puedas bisecar y una revisión que detecte cosas, no la ceremonia.