W3docs

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.

Confronto affiancato dei workflow feature branch, Gitflow e trunk-based

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:

WorkflowIndicato perCompromesso
Feature branchLa maggior parte dei teamSemplice; punto di partenza predefinito.
GitflowRilasci pianificati, prodotti con versioniStrutturato ma più pesante, con molti tipi di branch.
Trunk-basedContinuous delivery, CI solidaMolto veloce; richiede disciplina e feature flag.
ForkingOpen source, contributori non fidatiNon 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 main

Il 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 UI

Le 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.

Pratica

Pratica
Quali affermazioni sui Git workflow sono corrette?
Quali affermazioni sui Git workflow sono corrette?
Was this page helpful?