Release Branch in Git — cos'è, scopo e flusso di lavoro

Cos'è un Release Branch in Git

Release Branch (ramo di rilascio) è un ramo temporaneo in Git Flow, creato da develop quando il team decide che l'insieme corrente di funzionalità è pronto per il rilascio. Esiste esattamente per il tempo necessario alla preparazione finale del rilascio, da poche ore a qualche giorno.

Lo scopo principale di un ramo release è congelare un insieme specifico di funzionalità per il rilascio senza fermare lo sviluppo delle versioni successive. Mentre il ramo release viene preparato per la distribuzione, altri sviluppatori possono continuare a unire rami feature in develop per il prossimo rilascio.

Nel ramo release non vengono create nuove funzionalità, solo correzioni di bug, aggiornamento della versione dell'applicazione, localizzazione e documentazione. Dopo aver completato tutto il lavoro, il ramo release viene unito in main (marcato come rilascio) e di nuovo in develop (in modo che le correzioni arrivino alle versioni future).

Secondo Atlassian, 2024, i rami release sono di fondamentale importanza per i progetti con cicli di rilascio regolari, poiché garantiscono prevedibilità e stabilità del processo di pubblicazione.

Ciclo di vita del ramo release

Il ciclo di vita del ramo release, dalla creazione all'eliminazione, comprende diverse fasi. Comprendere ogni fase aiuta il team a sincronizzare le azioni ed evitare errori.

1. Creazione — dall'ultimo commit di develop viene creato un ramo chiamato release/2.5.0. develop continua ad accettare rami feature per la versione successiva.
2. Preparazione — nel ramo release, la versione dell'applicazione viene aggiornata in build.gradle, Info.plist e altri file di configurazione.
3. Correzione bug — gli errori critici trovati durante i test finali vengono corretti. Solo bug, senza nuove funzionalità.
4. Test finali — il team QA esegue test di regressione sul ramo release. I nuovi bug vengono inviati per la correzione nello stesso ramo.
5. Unione in main — il ramo release viene unito in main con il flag --no-ff. Viene creato il tag di rilascio: v2.5.0.
6. Unione in develop — il ramo release viene riunito in develop in modo che le correzioni del rilascio arrivino allo sviluppo corrente.
7. Eliminazione — il ramo release viene eliminato localmente e da remoto, poiché il suo compito è completato.

Il passo 6 — l'unione inversa in develop — viene spesso dimenticato, ma è di fondamentale importanza. Senza di esso, le correzioni apportate nel ramo release non raggiungeranno develop e gli stessi errori potrebbero ripresentarsi nel prossimo rilascio.

Durata tipica delle fasi del ramo release

La durata di vita del ramo release dipende dalla complessità del rilascio e dalla qualità del codice in develop. In media, la preparazione richiede da 2 a 5 giorni lavorativi per un'applicazione mobile di medie dimensioni.

Cosa si fa nel ramo release

Nel ramo release viene eseguito un insieme strettamente limitato di attività. Qualsiasi deviazione da questo elenco viola il modello Git Flow e crea rischi per la stabilità del rilascio.

La regola del divieto di nuove funzionalità è la più importante nel ramo release. Se una funzionalità non è pronta per il rilascio, aspetta il ciclo successivo. Tentare di introdurre una funzionalità incompleta nel ramo release è la causa principale di superamento delle scadenze e bug in produzione.

Aggiornamento della versione in un progetto mobile

Nel ramo release, il numero di versione dell'applicazione viene obbligatoriamente aggiornato. Per Android, questi sono i campi versionCode e versionName in build.gradle; per iOS — CFBundleShortVersionString in Info.plist.

// build.gradle (a livello di app) — aggiornamento versione nel ramo release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Per iOS — aggiornamento di Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Differenze tra release e hotfix

Gli sviluppatori principianti spesso confondono i rami release e hotfix, sebbene i loro scopi siano fondamentalmente diversi. Scegliere il tipo di ramo sbagliato può ritardare una correzione critica o interrompere il processo di rilascio.

• Origine — release viene creato da develop, hotfix da main. Questa è la differenza principale che determina tutto il resto.
• Urgenza — release è pianificato: il team decide quando iniziare la preparazione. Hotfix è urgente: un problema in produzione richiede una correzione immediata.
• Contenuto — release può includere più correzioni e aggiornamento di versione. Hotfix contiene una sola correzione critica.
• Unione — release viene unito in main e develop. Hotfix viene anch'esso unito in main e develop, ma con priorità.
• Durata — release vive da 1 a 7 giorni. Hotfix vive da 30 minuti a 1 giorno.

Se un bug viene trovato durante la preparazione del rilascio (nel ramo release), è una correzione normale. Se un bug viene trovato in produzione (su main), è un hotfix e viene creato da main, anche se il ramo release esiste già.

Regole di denominazione dei rami release

Uno standard unificato di denominazione dei rami release semplifica la navigazione del repository e consente ai sistemi CI/CD di rilevare automaticamente che un ramo appartiene al processo di rilascio.

• release/X.Y.Z — formato standard Git Flow, dove X.Y.Z è la versione del rilascio. Esempio: release/2.5.0.
• release/nome — formato alternativo con un nome in codice del rilascio. Esempio: release/merlin.
• release/data — formato con la data di rilascio. Usato raramente poiché la versione è più importante della data. Esempio: release/2024-12-01.

Il formato release/X.Y.Z è preferito perché lega esplicitamente il ramo al numero di versione che verrà assegnato al rilascio. Ciò semplifica la ricerca e l'elaborazione automatica tramite script CI/CD.

Strategia di unione inversa in develop

L'unione inversa (merge back) del ramo release in develop è una delle operazioni più importanti e allo stesso tempo più spesso trascurate. Senza di essa, tutte le correzioni apportate nel ramo release rimangono solo nella versione di rilascio e non raggiungono il successivo ciclo di rilascio.

Il processo di unione inversa viene eseguito dopo che il ramo release è già stato unito in main. Prima, release viene unito in develop, poi eliminato. Ciò garantisce che develop contenga tutte le correzioni apportate durante la preparazione del rilascio.

Dopo l'unione inversa, possono verificarsi conflitti, specialmente se in develop sono già comparsi nuovi rami feature che hanno modificato gli stessi file. Lo sviluppatore responsabile del rilascio risolve questi conflitti e invia develop al server.

Alcuni team usano rebase invece di merge per l'unione inversa per mantenere una cronologia lineare. Tuttavia, merge è più sicuro per develop perché non riscrive la cronologia dei commit che potrebbe già essere utilizzata da altri sviluppatori.

Esempi di comandi per lavorare con release

Esaminiamo il ciclo completo di lavoro con un ramo release: dalla creazione all'eliminazione dopo un rilascio riuscito di un'applicazione mobile versione 2.5.0.

# 1. Creare ramo release da develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Aggiornare versione e correzioni
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Correggere bug (solo bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Inviare ramo release al server
git push origin release/2.5.0

# 5. Unire release in main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Unione inversa in develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Eliminare ramo release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

I comandi 5 e 6 — la doppia unione — sono di fondamentale importanza. Prima, main riceve il codice di rilascio e il tag, poi develop si sincronizza con le correzioni di release. Se il passo 6 viene saltato, le correzioni del rilascio non raggiungeranno il prossimo ciclo di sviluppo.

Automazione del processo di rilascio

Per i progetti mobile con rilasci regolari, il processo di creazione di un ramo release e aggiornamento della versione può essere automatizzato tramite script CI/CD. GitHub Actions consente di creare un flusso di lavoro che, alla pressione di un pulsante, crea un ramo release con aggiornamento automatico della versione.

Per i progetti mobile con rilasci regolari, il processo di creazione di un ramo release e aggiornamento della versione può essere automatizzato tramite script CI/CD. GitHub Actions consente di creare un flusso di lavoro che, alla pressione di un pulsante, crea un ramo release con aggiornamento automatico della versione.

# GitHub Actions — automazione della creazione del ramo release
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}