Git è potente ma opinionated. Ci sono mille modi di usarlo, e scegliere quello sbagliato rallenta il team. Dopo anni di iterazione, ecco il workflow che funziona per noi.
Trunk-based development
Dimenticate GitFlow con le sue mille branch. Un solo branch principale (main), feature branch di vita breve (1-2 giorni max), merge frequenti. Less is more.
Feature branch lunghi divergono, generano conflitti, nascondono problemi. Merge piccoli e frequenti sono più facili da revieware e più sicuri da deployare.
Commit message che raccontano
Un commit dovrebbe essere una storia: cosa cambia e perché. "fix bug" non aiuta nessuno. "Fix null pointer when user has no profile picture" aiuta chi debugga tra sei mesi.
Code review come conversazione
La review non è un esame. È una conversazione tra colleghi. Fate domande invece di dare ordini. "Perché questa scelta?" invece di "Fai così". Il codice migliora, e anche il team.
Rebase con cautela
Rebase mantiene la storia lineare e pulita. Ma su branch condivisi, può creare caos. Regola semplice: rebase solo prima del primo push. Dopo, merge.