Perché `main` È Sacro

"Main è sempre verde" significa una cosa: in qualsiasi momento, il branch main è deployabile in produzione. Non "funziona per lo più", non "funziona se sai quali commit saltare" — deployabile. Adesso. Senza intervento manuale.

Questo è uno standard più alto di quanto la maggior parte dei team realizzi. Significa che ogni commit su main ha superato i test automatizzati, è stato revisionato da un essere umano e non dipende da lavoro incompleto di un altro branch. Significa che puoi fare il deploy venerdì alle 16:00 senza ansia, perché main non è un work-in-progress — è il prodotto finito ad ogni commit.

Il meccanismo che lo garantisce è la continuous integration (CI). Ogni PR esegue la suite di test, il linter e il type checker prima di poter fare il merge. Se qualche controllo fallisce, la PR viene bloccata. L'ingegnere corregge il problema sul proprio branch — non su main, non dopo il merge, non "più tardi". La CI è il guardiano che assicura che main non si degradi mai.

I team senza questa disciplina si trovano regolarmente in uno stato in cui main è rotto e nessuno sa quale degli ultimi cinque merge l'ha causato. A quel punto, tutti nel team sono bloccati — non possono fare pull del codice aggiornato, non possono avviare nuovi branch da uno stato funzionante e non possono fare deploy. Il costo di un main rosso non è il problema di un ingegnere. È il problema dell'intero team, che si aggrava ogni minuto in cui rimane rotto.

Le regole di protezione del branch sono l'applicazione automatizzata di "main è sempre verde". Ogni principale piattaforma di hosting Git — GitHub, GitLab, Bitbucket — le supporta, e dovrebbero essere configurate dal primo giorno di qualsiasi progetto serio.

Le tre regole che contano di più:

• Review obbligatorie delle PR. Nessun push diretto su main. Ogni modifica passa attraverso una PR e almeno un'approvazione. Questo intercetta l'impulso "faccio solo questo fix veloce" che rappresenta una quota sproporzionata degli incidenti in produzione.
• Controlli di stato obbligatori. La CI deve passare prima del merge. Test, linting, type checking — qualunque cosa esegua la tua pipeline. Un controllo fallito blocca il pulsante di merge. Nessun override, nessun "lo correggo nel prossimo commit".
• Cronologia lineare. Richiedi che i branch siano aggiornati con main prima del merge (rebase o merge-queue). Questo previene la situazione in cui due PR passano ciascuna la CI individualmente ma si rompono quando combinate — perché ogni PR viene testata contro lo stato attuale di main, non uno snapshot obsoleto.

Alcuni team resistono alle regole di protezione perché sembrano un attrito. Sono un attrito — un attrito intenzionale che previene la classe più costosa di errori. Configurare queste regole richiede cinque minuti. Recuperare da un force-push che sovrascrive il lavoro di un collega richiede ore, più il danno alla fiducia. Il calcolo non è nemmeno vicino.

Quando un deploy rompe la produzione, gli ingegneri affrontano una scelta: correggere in avanti o fare revert. L'istinto è quasi sempre correggere in avanti — trovare il bug, scrivere una patch, fare push. Ma quell'istinto è sbagliato sotto pressione.

Un revert è un singolo comando che annulla un commit noto in modo pulito:

git revert abc123f
# Creates a new commit that undoes abc123f
# Main is green again in minutes

L'alternativa del fix-in-panico è questa: un ingegnere curvo sulla tastiera alle 23:00, che scrive nuovo codice sotto pressione, saltando i test perché "è solo un fix di una riga", facendo push direttamente su main perché "non abbiamo tempo per una PR". Quel fix di una riga introduce un secondo bug il 40% delle volte, perché il codice scritto sotto adrenalina è codice scritto senza contesto completo.

La regola è semplice: prima revert, poi fix. Riporta main a verde immediatamente — questo sblocca l'intero team e ferma l'emorragia. Poi, senza pressione, scrivi un fix appropriato su un branch con test, review e CI. Il fix viene rilasciato un'ora o un giorno dopo, ma viene rilasciato correttamente.

I revert sembrano ammettere un fallimento. Non lo sono. Sono il percorso più veloce verso uno stato funzionante, e lasciano il commit originale nella cronologia come documentazione di cosa è andato storto. Un team che fa revert rapidamente è un team che rilascia con fiducia, perché il costo di un deploy sbagliato è minuti di downtime piuttosto che ore di emergenza.