Git Branch: guida a creazione, gestione e merge dei branch

Se hai mai lavorato a un progetto di coding di gruppo, sai quanto in fretta tutto può andare fuori controllo quando più persone provano ad aggiornare gli stessi file in parallelo. Nascono conflitti, si insinuano bug e i progressi si fermano. È qui che entrano in gioco i branch di Git: non come un trucco avanzato, ma come la base per uno sviluppo pulito e in parallelo.

In Git, creare branch non è solo consigliato: è la norma. Che tu stia sperimentando una nuova funzionalità, correggendo un bug o rivedendo il codice di qualcun altro, i branch ti permettono di lavorare senza pestare i piedi a nessuno. Puoi rompere le cose, iterare e poi integrare ordinatamente le tue modifiche nel codebase principale.

Questa guida ti accompagna attraverso gli elementi essenziali del branching in Git. Partiremo da git branch e git checkout, poi vedremo più da vicino come vengono creati, gestiti, uniti e cancellati i branch. Parleremo anche delle best practice per mantenere un workflow senza conflitti. Spero che, alla fine di questa guida, avrai una comprensione più ampia oltre la semplice memorizzazione dei comandi: capirai meglio il flusso di lavoro. Se tutto questo ti interessa e vuoi continuare a esercitarti, il nostro corso Introduction to GitHub Concepts è un ottimo punto di partenza.

Capire i branch in Git

Ora che abbiamo impostato il contesto, vediamo cos'è un branch in Git. In sostanza, un branch non è una cartella separata o una copia completa del tuo codebase: è semplicemente un puntatore leggero a un commit specifico. Questo è uno dei motivi per cui Git si distingue rispetto ai vecchi sistemi di controllo versione: creare branch è veloce, poco costoso e centrale nei workflow quotidiani.

Pensa a un branch come a una linea temporale. Quando crei un nuovo branch, in pratica stai dicendo: "Da qui esploriamo un nuovo percorso". Tutte le tue modifiche vivono su questo percorso finché non decidi di unirle di nuovo alla linea principale o meno. Questa flessibilità rende facilissimo provare idee, sviluppare funzionalità in isolamento e collaborare senza intaccare il codice stabile.

Git tiene traccia della tua posizione corrente nel progetto usando un riferimento speciale chiamato HEAD. Quando cambi branch, HEAD punta alla punta del nuovo branch. Questo dettaglio dietro le quinte permette a Git di cambiare contesto così velocemente, ed è anche ciò che rende comandi come git checkout e git switch così fluidi una volta che capisci cosa succede sotto il cofano.

Capendo come funzionano i branch in Git, sbloccherai la capacità di organizzare il tuo workflow di sviluppo con chiarezza e sicurezza. Se stai seguendo e vuoi testare questi concetti, il corso Intermediate Git di DataCamp affronta i branch con molta pratica guidata.

Elencare e visualizzare i branch Git

Hai creato branch e hai iniziato a usarli, ma come tieni traccia di tutto? Per fortuna, Git offre strumenti semplici ma potenti per elencare, ordinare e filtrare i branch, così da non perdere mai di vista il tuo workflow.

Verificare il branch corrente

Per iniziare, vediamo quali branch esistono nel tuo repository locale e identifichiamo su quale ti trovi in questo momento.

git branch

Questo comando elenca tutti i tuoi branch locali. Noterai un asterisco (*) accanto al branch corrente. Per una vista ancora più mirata, prova:

git branch --show-current

Questo restituisce solo il nome del branch su cui stai lavorando, in modo pulito e chiaro.

Vuoi vedere anche i branch remoti? Usa:

git branch -r

E se vuoi visualizzare contemporaneamente sia i branch locali che quelli remoti:

git branch -a

Questo ti offre un quadro completo della struttura dei branch del progetto, particolarmente utile quando collabori su piattaforme come GitHub. 

Ordinare e filtrare i branch

Con la crescita del progetto, crescerà anche l'elenco dei branch. Ordinare e filtrare ti aiuta a gestirlo efficacemente. Per ordinare i branch in base alla data dell’ultimo commit, usa:

git branch --sort=-committerdate

Puoi anche ordinare per altri criteri, come nome dell’autore, data di creazione o configurazione dell’upstream. Ecco un comando utile per filtrare i branch che contengono un commit specifico:

git branch --contains <commit>

Questo mostra quali branch hanno già incluso un dato commit, utile per verificare se una correzione o una funzionalità è stata integrata. Al contrario, il comando seguente mostra quali branch non hanno ancora recepito quel commit:

git branch --no-contains <commit>

Gestire i branch in modo efficace significa crearli, ma anche garantirne visibilità e controllo. Questi comandi aiutano a mantenere lo sviluppo pulito, organizzato ed efficiente.

Vuoi padroneggiare come tutto questo si collega alla collaborazione? Il corso Foundations of Git offre un’ottima base e copre workflow reali che userai ripetutamente.

Creare un nuovo branch Git

Ora che sai come elencare e passare tra i branch, vediamo come crearli. Il branching è una parte fondamentale del workflow di Git e, fortunatamente, creare nuovi branch è semplice, che tu stia impostando un feature branch, un hotfix o sperimentando qualcosa di completamente nuovo.

Creare un branch senza passarci

A volte vuoi creare un branch senza passarci subito. È utile quando stai preparando più branch in una volta o quando imposti workflow per altri.

git branch new-feature

Questo comando crea un branch chiamato new-feature, ma resterai sul branch corrente. Potrai passarci in seguito quando sarai pronto a lavorarci.

Creare e passare a un branch contemporaneamente

Se parti subito con lo sviluppo, puoi creare e passare al nuovo branch in un solo passaggio. Nelle versioni più vecchie di Git avresti usato:

git checkout -b new-feature

Tuttavia, nelle versioni moderne di Git, l'approccio più chiaro e intuitivo è:

git switch -c new-feature

Questo non solo crea il branch, ma lo effettua anche immediatamente, così sei pronto a iniziare a lavorare.

Impostare i branch upstream

Quando lavori con repository remoti, spesso vorrai che il tuo branch locale tenga traccia di uno remoto. Questo semplifica il push e il pull degli aggiornamenti. Per creare un branch che tenga traccia di un branch remoto fin da subito, usa:

git branch --track new-feature origin/new-feature

Se hai già creato il branch e vuoi impostare o cambiare l’upstream, questo comando fa al caso tuo:

git branch --set-upstream-to=origin/new-feature

Questa configurazione assicura che il tuo branch locale sappia da quale branch remoto recuperare o verso quale inviare, mantenendo il tuo workflow fluido e connesso.

Passare tra branch Git

Dopo aver creato qualche branch, ti capiterà spesso di saltare tra l’uno e l’altro, che si tratti di tornare su main per unire una correzione o di passare a un feature branch per continuare a codificare. Git rende questo processo fluido e, come spesso accade con Git, esistono più modi per farlo.

Usare git checkout

Per molto tempo, git checkout è stato il comando di riferimento per cambiare branch:

git checkout feature-login

Questo comando passa la tua working directory al branch feature-login, aggiornando tutti i file per riflettere lo snapshot di quel branch. È affidabile e ancora ampiamente usato. Ma ecco il punto: git checkout fa tante cose. Serve per cambiare branch, ripristinare file e persino effettuare il checkout di commit. Può confondere, soprattutto all’inizio.

Usare git switch

Per rendere tutto più intuitivo, Git ha introdotto the git switch nella versione 2.23:

git switch feature-login

Fa esattamente ciò che ti aspetti: cambia branch. Non tocca la tua working tree né reimposta i file a meno che tu non glielo chieda. È più semplice, sicuro e facile da insegnare e ricordare.

Quindi, quando usare cosa?

• Usa git switch per passare tra branch: è chiaro e pensato apposta per questo.
• Usa git checkout se devi ripristinare file o effettuare il checkout di un commit specifico.

Eseguire il merge dei branch Git

Hai lavorato a una funzionalità su un branch separato. Ora arriva il momento della verità: combinare le tue modifiche nel branch principale. In Git, questo processo si chiama merge. A seconda della storia dei tuoi branch, ci sono diversi modi per affrontarlo.

Fast-forward merge

Diciamo che il tuo feature branch è partito da the main e, mentre ci lavoravi, nessun altro ha toccato main. In questo caso, Git non deve “pensare” molto. Semplicemente sposta il puntatore di main in avanti fino all’ultimo commit di feature-branch.

git checkout main
git merge feature-branch

Non viene creato alcun nuovo commit: Git esegue un fast-forward di main. Pulito, semplice e perfetto per progetti in solitaria o branch di breve durata.

Merge a tre vie

Le cose si fanno più interessanti quando entrambi i branch sono avanzati indipendentemente. Magari un tuo collega ha aggiunto modifiche su main mentre tu lavoravi su the feature branch. Ora Git deve guardare a tre snapshot: l’antenato comune, il tuo branch e il branch di destinazione.

git checkout main
git merge feature-branch

In questo caso, Git crea un nuovo merge commit per combinare i due branch. Se ci sono conflitti, ad esempio tu e il tuo collega avete modificato la stessa riga nello stesso file, Git ti chiederà di risolverli manualmente. Modificherai il file, lo segnerai come risolto e poi effettuerai il commit del merge.

git add .
git commit

Se tutto questo ti sembra un po’ intimidatorio, il nostro Git Merge Tutorial: A Comprehensive Guide with Examples è un’ottima guida che copre tutti gli elementi essenziali, inclusa la gestione dei conflitti in modo efficace.

Rebase invece del merge

Non ti piacciono i merge commit che affollano la cronologia? Non sei il solo. Qui entra in gioco Git rebase. Invece di creare un nuovo merge commit, rebase riproduce le tue modifiche sopra un altro branch, ottenendo una cronologia più pulita e lineare.

git checkout feature-branch
git rebase main

Poi, quando esegui il merge, Git vede una linea retta: non c’è bisogno di un merge commit. Tuttavia, usalo con cautela, soprattutto quando lavori su branch condivisi. Riscrivere la cronologia può essere rischioso se altri stanno lavorando sullo stesso codice.

Per capire quando è meglio usare merge o rebase (e come fare rebase in sicurezza), il corso Intermediate Git offre indicazioni pratiche e hands-on.

Eliminare branch Git

Dopo un merge riuscito, è buona pratica pulire i branch che non ti servono più, sia in locale che in remoto. Mantiene l’ambiente ordinato e la cronologia di Git più facile da navigare. Vediamo come farlo senza perdere il sonno per aver cancellato qualcosa di importante.

Eliminare branch locali

Quando un branch è stato unito e ha concluso il suo compito, puoi eliminarlo in sicurezza dal tuo repository locale:

git branch -d feature-branch

Il flag -d sta per “delete”. Git controllerà che il branch sia già stato unito per evitare potenziali perdite di dati.

Ma se vuoi eliminare un branch anche se non è stato unito? Entra in gioco la maiuscola -D:

git branch -D feature-branch

Questo forza l’eliminazione anche se Git ti avvisa che il branch non è stato unito. Prima di premere invio, assicurati solo che quelle modifiche non ti servano.

Cerchi un approfondimento sulla gestione del workspace locale e dei branch? Dai un’occhiata al nostro tutorial Git Pull Force: How to Overwrite a Local Branch With Remote. È un utile complemento per assicurarti di non solo eliminare, ma gestire i branch in sicurezza.

Eliminare branch remoti

La pulizia locale è solo metà del lavoro. Se il branch esiste anche su un remoto (come GitHub), vorrai rimuoverlo anche lì, soprattutto se hai finito con la funzionalità o il bug fix.

git push origin --delete feature-branch

Questo comando dice a Git di rimuovere il branch dal remoto origin. È pulito e diretto, e aiuta a evitare che il remoto si riempia di branch inutilizzati.

Una volta eliminati i branch remoti, è anche una buona idea pulire i riferimenti locali di tracciamento.

git fetch -p

La -p sta per "prune". Rimuove eventuali branch di tracciamento remoti obsoleti che non esistono più sul server.

Per altre buone abitudini di igiene in Git, i tutorial Git Push and Pull Tutorial e la Complete Git Cheat Sheet sono ottimi riferimenti rapidi.

Eseguire push e pull dei branch Git

Una volta creati e organizzati i branch in locale, il passo successivo è sincronizzarli con il repository remoto. Questo è essenziale per la collaborazione e il backup. Vediamo come effettuare push, pull e tracking dei branch in modo efficace.

Effettuare il push di un nuovo branch sul remoto

Hai creato e testato una nuova feature in locale e ora vuoi condividerla con il team o salvarla in remoto. Per inviare un nuovo branch a un repository remoto (tipicamente chiamato origin), usa:

git push -u origin new-feature

Il flag -u (abbreviazione di --set-upstream) dice a Git di ricordare il branch remoto per i futuri pull e push. In questo modo, la prossima volta potrai semplicemente eseguire git pull o git push senza specificare il branch.

Se ti stai chiedendo cos’altro succede dietro le quinte durante un push o un pull, il nostro Git Push and Pull Tutorial lo spiega con esempi da seguire.

Recuperare modifiche da un branch remoto

Poniamo che qualcun altro abbia inviato aggiornamenti allo stesso branch su cui stai lavorando. Vorrai scaricare quelle modifiche per restare allineato:

Git pull origin new-feature

Questo recupera gli ultimi commit dal remoto e li unisce al tuo branch locale. Se vuoi evitare merge commit, considera l’uso di:

git pull --rebase origin new-feature

Come spiegato nella sezione sul merge, --rebase aiuta a mantenere pulita la cronologia dei commit.

Tracciare un branch remoto

Quando vuoi iniziare a lavorare con un branch che esiste già sul remoto, il modo più semplice per configurare tutto è:

git checkout --track origin/feature-xyz

Questo comando effettua il checkout del branch remoto e imposta automaticamente il tracking, così i futuri pull e push saranno semplicissimi.

Problemi comuni e risoluzione

Anche con i migliori workflow, non fila sempre tutto liscio. Che si tratti di un conflitto di merge, di un branch cancellato per errore o di modifiche non salvate che ti bloccano, Git ha strumenti per aiutarti a riprenderti. Vediamo alcuni dei problemi più comuni legati ai branch e come risolverli.

Gestire i conflitti di merge

Hai appena provato a unire un branch e Git segnala un conflitto di merge. Succede quando due branch modificano in modo diverso la stessa parte di un file e Git non sa quale modifica mantenere.

Ecco come affrontarlo:

git status

Questo ti dice quali file sono in conflitto. Poi puoi usare:

git diff

Per vedere cosa causa il problema. Da lì, apri manualmente i file in conflitto, risolvi le differenze e poi

git add <resolved-file>
git commit

Se vuoi approfondire i workflow di merge e la risoluzione dei conflitti, consulta il Git Merge Tutorial, che offre una guida completa.

Recuperare branch eliminati

Hai eliminato accidentalmente un branch e inizia a salire il panico? Niente paura: non è perso per sempre se agisci in fretta.

Puoi recuperarlo con git reflog, che registra le posizioni recenti di HEAD:

git reflog

Trova l’hash del commit precedente all’eliminazione del branch, poi ricrealo con:

git checkout -b your-branch-name <commit-hash>

E proprio così, il tuo branch è tornato. Vuoi capire meglio come Git traccia questi riferimenti? La nostra Guida a Git Reflog lo spiega con esempi reali.

Mettere da parte le modifiche prima di cambiare branch

A volte vuoi cambiare branch, ma hai modifiche non ancora salvate con un commit. Git non ti farà cambiare se potrebbe comportare la perdita di lavoro. Qui entra in gioco git stash.

git stash

E Git metterà temporaneamente da parte le tue modifiche. Dopo aver cambiato branch, puoi riprenderle con:

git stash pop

Questo è particolarmente utile quando salti tra feature o hotfix.

Se stai gestendo molte modifiche o stai ripulendo la working directory, potrebbe interessarti anche Git Clean: Remove Untracked Files and Keep Repos Tidy.

Strategie avanzate di branching

A questo punto hai visto come creare, cambiare e gestire i branch di Git con facilità. Ma come usano questi branch i team nei progetti reali? La risposta sta nello scegliere la strategia di branching giusta: una struttura che definisce come e quando usare i branch nel tuo workflow di sviluppo. Esploriamo alcuni degli approcci più diffusi.

Feature branch workflow

Il feature branch workflow è una delle strategie più comuni, soprattutto nei progetti collaborativi. Ecco come funziona:

Ogni nuova funzionalità ha il suo branch, creato da main (o develop). Questo permette agli sviluppatori di lavorare in modo indipendente senza toccare il codice pronto per la produzione.

git switch -c feature/login-page

Una volta completata e testata la feature, si esegue il merge nel branch principale (o in uno di staging) tramite una pull request.

Questo modello aiuta a isolare il lavoro, rende le code review più gestibili ed evita di riempire il branch principale con feature a metà. Per mantenere fluida la collaborazione remota, non dimenticare di inviare i tuoi branch:

git push -u origin feature/login-page

Hai bisogno di un ripasso su push e pull dei branch? Il Git Push and Pull Tutorial ti guida in tutto il processo.

Workflow GitFlow

Se lavori a un progetto con release regolari, GitFlow potrebbe fare al caso tuo. Questo workflow introduce ruoli strutturati per diversi tipi di branch:

• main: contiene sempre codice pronto per la produzione.

• develop: branch di integrazione per le feature.

• feature/*: branch di breve durata per nuove funzionalità.

• release/*: branch pre-produzione per i test.

• hotfix/*: correzioni rapide basate su main.

Ecco un esempio rapido di avvio di una nuova feature usando gli strumenti GitFlow:

git flow feature start payment integration

Questa strategia aggiunge un po’ di complessità, ma dà il meglio in team più grandi, dove struttura chiara e stabilità sono priorità. Se stai esplorando workflow oltre GitHub, dai un’occhiata a What GitLab Is: Features, Benefits, and How to Get Started per un’altra prospettiva sulle pratiche strutturate in Git.

Trunk-based development

Preferisci pochi branch e rilascio rapido? Il trunk-based development potrebbe fare per te. In questa strategia, tutti gli sviluppatori fanno commit su un unico branch, di solito main, con commit piccoli e frequenti. Invece di feature branch di lunga durata, questo approccio incoraggia branch di breve durata o commit diretti su main.

È veloce e lineare, ma richiede disciplina, forte automazione dei test e buona comunicazione. Questo modello è comune nelle startup e nei team che praticano DevOps o CI/CD. Scegliere una strategia di branching dipende dalla dimensione del team, dalla cadenza dei rilasci e, naturalmente, dal livello di collaborazione.

Conclusione

I branch sono il cuore del sistema di controllo versione di Git. Consentono agli sviluppatori di lavorare su nuove funzionalità, correzioni di bug ed esperimenti in isolamento, senza interrompere il codebase principale. Questa flessibilità porta a workflow più puliti e organizzati e a una collaborazione migliore nel team.

Eseguendo commit frequenti, facendo merge in modo responsabile e mantenendo una struttura dei branch pulita, riduci il rischio di conflitti e rendi il tuo codebase più semplice da navigare e mantenere. Senza dubbio, padroneggiare i branch di Git ti aiuta a consegnare software migliore nel tempo.