Main e Master Branch in Git: cos'è e perché serve un ramo principale

Cos'è Main / Master Branch in Git

Main Branch (o Master — a seconda delle impostazioni del repository) è il ramo predefinito creato durante l'inizializzazione di qualsiasi repository Git. È il ramo principale del progetto e contiene codice pronto per il deployment in produzione.

A differenza di develop, dove il lavoro quotidiano con nuove funzionalità è in pieno svolgimento, main è la vetrina del progetto. Ogni versione del codice in main ha attraversato un ciclo completo: sviluppo in un ramo feature, integrazione in develop, preparazione del rilascio in un ramo release e test finali. Solo dopo questi passaggi le modifiche arrivano a main.

Principio chiave: main deve essere sempre stabile. Se viene trovato un errore in main, significa che è necessario un hotfix urgente fuori programma. Pertanto, nei progetti professionali, main è protetto da modifiche accidentali tramite regole di protezione del ramo.

Secondo Git Book, main non è un ramo speciale con proprietà uniche, ma un normale riferimento a un commit che per convenzione è considerato principale. Git non fa distinzione tra main e qualsiasi altro ramo a livello di sistema.

Transizione da master a main

Storicamente, il ramo predefinito in Git si chiamava master. Nel giugno 2020, il movimento Black Lives Matter ha attirato l'attenzione sui termini master e slave nell'industria IT. GitHub ha annunciato la transizione al termine main per il ramo predefinito.

Da ottobre 2020, tutti i nuovi repository su GitHub vengono creati con il ramo main. GitLab e Bitbucket hanno anche implementato il supporto per main come nome predefinito. Git 2.28 (luglio 2020) ha aggiunto l'opzione init.defaultBranch per configurare il nome del ramo predefinito.

Tecnicamente, rinominare un ramo esistente da master a main è un'operazione semplice. La sfida principale è aggiornare tutti i riferimenti nelle configurazioni CI/CD, nella documentazione e nei repository locali degli sviluppatori.

Per rinominare un ramo in un repository esistente, esegui:

# Rinominare localmente master in main
git branch -m master main

# Aggiornare il repository remoto
git push -u origin main

# Eliminare il vecchio master sul server
git push origin --delete master

# Aggiornare HEAD sul server
# (tramite interfaccia web GitHub: Settings → Branches → Default branch)

Ruolo di main in Git Flow e GitHub Flow

Git Flow e GitHub Flow definiscono il ruolo del ramo main in modo diverso. La scelta del modello dipende dalle dimensioni del team, dalla frequenza dei rilasci e dai requisiti di stabilità del codice.

Per lo sviluppo mobile, Git Flow è lo standard, poiché la pubblicazione di un'app nell'App Store e Google Play ha cicli di rilascio fissi. GitHub Flow è più adatto per progetti web che possono essere distribuiti più volte al giorno.

GitHub Flow — approccio semplificato

In GitHub Flow, non esiste un ramo develop. Tutti i rami feature vengono creati direttamente da main e, una volta completati, vengono uniti tramite una Pull Request. Ogni unione in main attiva automaticamente il deployment in produzione. Questo modello richiede un alto livello di automazione dei test e disciplina del team.

In GitHub Flow, non esiste un ramo develop. Tutti i rami feature vengono creati direttamente da main e, una volta completati, vengono uniti tramite una Pull Request. Ogni unione in main attiva automaticamente il deployment in produzione. Questo modello richiede un alto livello di automazione dei test e disciplina del team.

Protezione del ramo main

La protezione del ramo per main è un'impostazione obbligatoria in qualsiasi progetto commerciale. Senza di essa, un push accidentale potrebbe inviare codice incompleto in produzione o rompere un'applicazione funzionante per tutti gli utenti.

• Require pull request — il push diretto a main è vietato. Tutte le modifiche tramite PR con revisione.
• Require approvals — minimo 2 approvazioni per unire in main (nel caso in cui un revisore perda qualcosa).
• Require status checks — tutti i controlli CI/CD devono essere superati prima dell'unione.
• Require up-to-date — la PR deve basarsi sull'ultimo commit di main.
• Include administrators — la protezione si applica anche ai proprietari del repository.
• Require signed commits — tutti i commit in main devono essere firmati con una chiave GPG.

Configurare tutte e sei le regole è lo standard per i progetti mobile con 10.000+ utenti. Per i progetti piccoli, le prime tre regole sono sufficienti.

Confronto dei livelli di protezione per diversi tipi di progetto

Il livello di protezione di main dipende dalla scala del progetto. Una startup può cavarsela con una protezione minima, mentre un'applicazione enterprise richiede restrizioni massime.

Rilasci e tag in main

Tagging è la pratica di creare riferimenti nominati a commit specifici in main. Ogni tag corrisponde a una versione dell'applicazione rilasciata in produzione. Ciò consente di passare rapidamente a qualsiasi versione precedente per debug o patch.

Lo standard di denominazione dei tag nello sviluppo mobile è SemVer (Versionamento Semantico): v1.2.3, dove il primo numero è la versione major (modifiche radicali), il secondo è la versione minor (nuove funzionalità) e il terzo è la patch (correzioni).

Un tag viene creato dopo l'unione del ramo release in main. Questo commit viene poi compilato in CI/CD, firmato e inviato all'app store. Se viene trovato un errore nel tag, viene creato un ramo hotfix da quel tag.

# Creare un tag di rilascio annotato
git tag -a v2.4.1 -m "Release version 2.4.1"

# Inviare il tag al server
git push origin v2.4.1

# Visualizzare tutti i tag nel repository
git tag -l "v2.*"

# Creare un ramo hotfix da un tag specifico
git checkout -b hotfix/crash-fix v2.4.1

Gerarchia dei rami Git Flow

Comprendere la gerarchia dei rami in Git Flow è la base per organizzare correttamente lo sviluppo collaborativo. Ogni tipo di ramo ha la propria fonte, scopo e regole di unione.

• Main (Livello 1) — il ramo radice, contiene solo versioni di rilascio. Creato all'inizializzazione del repository.
• Develop (Livello 2) — creato da main all'avvio del progetto. Contiene il codice di integrazione di tutte le funzionalità.
• Feature (Livello 3) — creato da develop. Sviluppo isolato di funzionalità individuali.
• Release (Livello 2) — creato da develop. Preparazione di un rilascio specifico per il lancio.
• Hotfix (Livello 2) — creato da main. Correzione urgente di errori critici di produzione.

Regola importante: feature non viene mai unita direttamente in main. feature → develop → release → main è la catena di unione corretta. Violare questa regola vanifica lo scopo dell'intero modello Git Flow.

Esempi di comandi per lavorare con main

Consideriamo uno scenario: il team ha completato la preparazione del rilascio v2.5.0. Il ramo release è stato verificato ed è pronto per essere unito in main. Dopo l'unione, viene creato un tag e il rilascio viene pubblicato.

# Passare a main e aggiornare
git checkout main
git pull origin main

# Unire il ramo release verificato
git merge --no-ff release/2.5.0

# Creare un tag di rilascio
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Inviare main e il tag al server
git push origin main --tags

Il flag --no-ff (no fast-forward) garantisce la creazione di un commit di unione, anche se l'unione avrebbe potuto essere eseguita semplicemente spostando il puntatore. Questo preserva l'informazione che le modifiche provenivano da un ramo release, facilitando l'analisi della cronologia.

Lavorare con hotfix attraverso main

Se viene scoperto un errore critico in produzione, il processo differisce da un rilascio normale. Un hotfix viene creato da main e, dopo la correzione, viene unito sia in main che in develop.

Se viene scoperto un errore critico in produzione, il processo differisce da un rilascio normale. Un hotfix viene creato da main e, dopo la correzione, viene unito sia in main che in develop.

# Creare un ramo hotfix da main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Correggere e fare commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Unire hotfix di nuovo in main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Unire hotfix anche in develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Eliminare il ramo hotfix
git branch -d hotfix/2.5.1-crash-fix