Perché uso Git come discriminante quando valuto un team

Vuoi sapere in fretta se un team di sviluppo fa sul serio? Guarda come usa Git. Non lo strumento in sé — branching strategy, messaggi di commit, code review, chi tocca cosa e quando. È il segnale più onesto di disciplina che conosca: dove c'è, il software regge; dove manca, trovo quasi sempre caos, bug e falle di sicurezza. Lo uso da anni come discriminante, e nel 2026 vale ancora.

TL;DR

Git non è un backup. È il modo in cui un team collabora senza pestarsi i piedi.
Una branching strategy chiara e commit leggibili separano i progetti gestibili da quelli ingestibili.
Nasce per questo: Linus Torvalds lo crea nel 2005 per coordinare migliaia di persone sul kernel Linux.
Onestà: nemmeno i miei repo pubblici sono perfetti. La disciplina è una pratica, non una posa.

Perché lo uso come test del tornasole

Quando valuto un team o un'azienda, non parto dal codice. Parto da come è tracciato. Se in un colloquio o in una due diligence scopro che Git è usato solo come "tasto destro → carica tutto", ho già metà della risposta. Non perché sia un dettaglio tecnico snob, ma perché il modo in cui versioni il lavoro racconta come pensi al lavoro: se ti importa di poter tornare indietro, di capire chi ha cambiato cosa, di non rompere ciò che funziona mentre costruisci il pezzo nuovo.

Sembra incredibile, ma nel 2026 — come nel 2014 — esistono ancora aziende del tutto estranee al concetto di organizzazione in team: niente workflow, niente branching, niente review. Poi le stesse aziende si lamentano che i loro progetti vanno male, sono disorganizzati, pieni di bug e — quasi sempre — di falle di sicurezza. Non è sfortuna. È la conseguenza diretta di lavorare senza un sistema condiviso per collaborare.

Da dove nasce davvero Git

Vale la pena ricordarlo, perché spiega tutto. Git non nasce in un'aula universitaria: lo scrive Linus Torvalds nel 2005, sotto pressione, perché doveva gestire il caos di migliaia di persone che contribuivano contemporaneamente al kernel Linux senza calpestarsi a vicenda. Gli serviva un modo efficiente e tracciabile per collaborare senza conflitti — letteralmente per avere il meno possibile a che fare con i colleghi e lasciare che il sistema mediasse il lavoro contemporaneo.

La cosa quasi assurda è che uno strumento costruito da una persona per organizzare il proprio casino sia diventato l'infrastruttura su cui si regge la prima vera community open source di massa. L'open source aveva bisogno esattamente di questo: un modo per far collaborare team sparsi, sconosciuti tra loro, senza un capo che coordinasse a mano. Git è la risposta a quel bisogno. Per questo, quando lo vedo usato male, sento che si butta via il senso stesso per cui esiste.

Cosa succede dove la disciplina manca

Senza disciplina di versioning	Con una branching strategy chiara
"Chi ha rotto la produzione?" → mistero	Ogni cambiamento ha un autore e un perché
Tornare indietro = panico	Rollback in un comando
Modifiche che si sovrascrivono a vicenda	Merge tracciati, conflitti risolti a vista
Sicurezza: segreti e bug entrano inosservati	Review prima del merge, traccia di tutto
Onboarding: "fidati, funziona così"	La storia del repo è la documentazione

Non sto dicendo che Git renda un team bravo. Sto dicendo che la sua assenza rende quasi impossibile esserlo oltre una certa scala. È il pavimento, non il soffitto.

Onestà: nemmeno i miei repo sono perfetti

Sarei ipocrita a non ammetterlo. Se guardi alcuni dei miei repository pubblici, vedi commit sgangherati, messaggi pigri, cronologie che non racconto con orgoglio — e questo già prima dell'arrivo dell'intelligenza artificiale. La disciplina di versioning è difficile proprio perché è una pratica continua, non un interruttore. Si scivola sotto pressione, esattamente quando servirebbe di più.

Per questo non la predico come dogma da chi è arrivato. La predico da chi ci combatte ogni giorno e sa quanto costa farne a meno. Ed è anche il punto da cui parte il prossimo capitolo: cosa succede quando la velocità — e l'AI — ti spingono a mollare proprio questa disciplina. L'ho fatto, di recente, e te lo racconto qui.

FAQ

Git serve anche se lavoro da solo?

Sì, e tanto. Anche da solo ti dà la possibilità di tornare indietro senza paura, di sperimentare su un branch e buttarlo, di capire cosa hai cambiato tra una versione che funziona e una che si è rotta. Il "collaboratore" con cui non vuoi conflitti, da solo, sei tu di tre settimane fa.

Serve una branching strategy complicata per un piccolo team?

No. Per la maggior parte dei team piccoli basta un flusso semplice: un branch principale sempre funzionante, branch brevi per ogni modifica, review prima del merge. La complessità si aggiunge solo quando il team cresce. Meglio un processo semplice e rispettato che uno elaborato e ignorato.

Usare Git male è peggio che non usarlo?

Quasi mai, ma il rischio esiste: un repo con cronologia ingannevole o branch abbandonati dà falsa sicurezza. La soluzione non è abbandonarlo, è darsi tre regole minime e rispettarle: branch per ogni lavoro, commit leggibili, niente merge senza review.

Se stai costruendo o riorganizzando un team tecnico e vuoi mettere ordine in workflow, architettura e processi, parliamone o guarda cosa faccio come Fractional CTO. E quando hai finito qui, leggi il rovescio della medaglia: ho mollato Git per la velocità, e l'AI me lo ha permesso.

Il logo di Git è di Jason Long, distribuito con licenza CC BY 3.0.