Git: guida completa dal primo commit al workflow professionale

Git è diventato lo standard indiscusso nel controllo versione, eppure molti sviluppatori lo usano senza davvero comprenderlo. Se stai ancora copiando comandi da Stack Overflow, è il momento di cambiare approccio. Questa guida ti porterà dalla tua prima commit fino a un workflow professionale vero.

I fondamentali: da zero a primo commit

Iniziamo con le basi che contano davvero. Git tiene traccia dei cambiamenti nel tuo codice attraverso tre aree principali: la working directory (dove lavori), la staging area (quello che stai per salvare) e il repository (la cronologia).

Il tuo primo repository inizia con git init. Poi aggiungi file con git add, committa con git commit -m "messaggio chiaro". Un messaggio di commit non è un optional: deve descrivere il "cosa" e il "perché", non il "come". "Fix bug login" è vago; "Correggi validazione email che accettava indirizzi senza @" è utile.

La regola d'oro: un commit = una logica atomica. Se cambiano 5 cose diverse, dovrebbero essere 5 commit diversi. Future you (e i tuoi colleghi) ringrazieranno.

Branching e collaborazione: dove Git diventa potente

I branch sono il superpower di Git. Non sono opzionali nei team professionali: sono obbligatori. git branch feature/login crea un nuovo branch isolato. git checkout (o git switch nella sintassi moderna) ti sposta tra branch.

Il workflow tipico è semplice: crei un feature branch da main, lavori in isolamento, poi apri una Pull Request (PR). Una PR non è solo per chiedere permesso di mergiare: è uno strumento di revisione, discussione e garanzia di qualità. Code review non è punitivo; è protezione collettiva.

Prima di merggiare, asicurati che il branch sia aggiornato rispetto a main con git rebase main o git merge main. Rebase mantiene la storia lineare e leggibile; merge preserva il contesto. In team professionali, la scelta dipende dalle convenzioni stabilite.

Workflow professionale: le pratiche che contano

Un workflow serio non è complicato, ma è disciplinato. Usa una strategia di branching: Git Flow per progetti complessi, GitHub Flow per deploy continui, GitLab Flow per environment specifici. Scegline una e rispettala.

Implementa commit signing con GPG per provare l'autenticità (critico per open source e compliance). Usa conventional commits (feat:, fix:, docs:) per messaggi strutturati. Configura pre-commit hooks che verificano linting e test prima che un commit vada nel repository.

Infine, mantieni la storia pulita. git rebase -i ti permette di squashare, riordenare o editare commit prima di pushare. Una storia pulita non è vanità: è manutenibilità futura.

Conclusione

Git non è uno strumento da imparare una volta e dimenticare. È il fondamento della collaborazione moderna. La differenza tra uno sviluppatore medio e uno senior spesso si vede nel modo in cui gestisce il controllo versione: con intenzionalità, disciplina e chiarezza.

Prossimo passo: scegli un progetto e implementa un workflow strutturato. Scrivi commit message come se dovessi spiegare il tuo codice a te stesso tra 6 mesi. Fai code review seriosamente. Questi non sono dettagli—sono l'eredità che lasci al tuo team.