Git workflow
Panoramica dei principali Git workflow — feature branch, Gitflow, trunk-based e forking — e come scegliere quello giusto per il tuo team.
Cos'è un Git workflow
Un Git workflow è un insieme condiviso di convenzioni su come un team usa branch, commit e merge per collaborare senza intralciarsi a vicenda. Git stesso è neutrale — fornisce gli strumenti ma non impone come usarli. Un workflow colma questo vuoto rispondendo a domande pratiche: dove vive il nuovo lavoro, come viene revisionato e come arriva in produzione.
Perché è importante
Senza un workflow condiviso, un team scivola rapidamente nel caos: lavoro non completato sul branch principale, conflitti di merge inaspettati e rilasci difficili da riprodurre. Un buon workflow mantiene il branch principale sempre pronto al rilascio, rende la revisione un passaggio naturale e offre a tutti lo stesso modello mentale di dove si trova il codice nel suo percorso.
Il workflow centralizzato
Il modello più semplice, e un buon punto di partenza per comprendere gli altri, è il workflow centralizzato: tutti fanno commit direttamente su un unico branch condiviso (di solito main). Non esistono feature branch — git pull e git push mantengono ogni sviluppatore sincronizzato con il repository centrale.
# Get the latest shared history before you start
git pull origin main
# ...make and commit your changes...
git add .
git commit -m "Add user profile page"
# Share your work; rebase on top of any new commits first
git pull --rebase origin main
git push origin mainÈ facile da capire, ma scala male: ogni commit finisce sul branch da cui dipendono i colleghi, quindi una modifica non terminata può bloccare tutti. I workflow descritti di seguito risolvono questo problema isolando prima il lavoro in branch separati.
I workflow più comuni
Questi quattro approcci si basano sull'idea centralizzata, ma aggiungono isolamento. Ognuno presenta diversi compromessi tra semplicità e struttura:
| Workflow | Indicato per | Compromesso |
|---|---|---|
| Feature branch | La maggior parte dei team | Semplice; punto di partenza predefinito. |
| Gitflow | Rilasci pianificati, prodotti con versioni | Strutturato ma più pesante, con molti tipi di branch. |
| Trunk-based | Continuous delivery, CI solida | Molto veloce; richiede disciplina e feature flag. |
| Forking | Open source, contributori non fidati | Non richiede accesso in scrittura; fork aggiuntivo da gestire. |
Un feature branch in azione
In pratica, la maggior parte dei team inizia con i feature branch perché i comandi sono familiari e l'isolamento è immediato. Il pattern è sempre lo stesso: crea un branch da main, fai il tuo lavoro, poi esegui il merge.
# Create and switch to an isolated branch
git switch -c feature/login
# ...edit files, then stage and commit...
git add .
git commit -m "Add login form"
# Bring the finished work back into main
git switch main
git pull origin main # make sure main is current
git merge feature/login # integrate the feature
git push origin mainIl branch mantiene main sempre pronto al rilascio mentre la funzionalità è ancora in sviluppo, e offre ai revisori un insieme coerente di commit da esaminare.
Pull request sopra qualsiasi workflow
Sulle piattaforme hosted come GitHub, GitLab o Bitbucket, di solito non si fa il merge in locale. Invece si fa il push del branch e si apre una pull request (chiamata "merge request" su GitLab): un luogo dove revisionare il diff, eseguire la CI e discutere prima che il codice raggiunga main.
git switch -c feature/login
# ...commit work...
git push -u origin feature/login # push branch, set upstream
# then open a pull request in the web UILe pull request non sono un workflow separato — sono una fase di revisione che puoi aggiungere al modello feature branch, Gitflow, trunk-based o forking allo stesso modo.
Come scegliere
Inizia con il workflow più semplice adatto alla tua situazione e aggiungi struttura solo quando senti il disagio di non averla.
- Un piccolo team che rilascia continuamente un'app web è ben servito dall'approccio feature branch o trunk-based.
- Un prodotto con rilasci programmati e versionati trae vantaggio dai branch espliciti di release e hotfix di Gitflow.
- Un progetto open source che accetta contributi da sconosciuti ha bisogno del modello forking, perché i contributori non hanno accesso in push al repository principale.
Questi workflow non si escludono a vicenda. Molti team combinano le idee — per esempio, usando feature branch di breve durata con una mentalità trunk-based, o le pull request sopra ognuno di essi.
Il filo conduttore
Ogni workflow qui si basa sugli stessi strumenti di base che hai già imparato: git branch, git switch, git merge, git rebase e git push. Il workflow è solo una convenzione sovrapposta a questi comandi. Padroneggia i comandi, concorda sulle convenzioni e la collaborazione diventerà notevolmente più fluida.