Feature Branch in Git: cos'è, come creare e lavorare con i rami

Cos'è un Feature Branch in Git

Feature Branch (ramo di funzionalità) è un ramo temporaneo in Git creato da develop per sviluppare una funzionalità specifica. A differenza dei rami longevi main e develop, i rami feature esistono per un tempo limitato — da poche ore a poche settimane.

Lo scopo principale del feature branch è isolare le modifiche relative a un'attività dal resto del codice. Lo sviluppatore può sperimentare, fare numerosi commit e persino rompere il codice nel proprio ramo senza influenzare il lavoro degli altri membri del team.

Dopo aver completato lo sviluppo, il ramo feature viene riunito in develop tramite una Pull Request con revisione del codice obbligatoria. Dopo l'unione, il ramo viene solitamente eliminato per mantenere pulito il repository.

Secondo Vincent Driessen, 2010, il modello Git Flow con rami feature è diventato uno standard industriale grazie alla chiara separazione delle responsabilità tra diversi tipi di rami.

Flusso di lavoro con Feature Branch

Il flusso di lavoro con feature branch consiste in una sequenza di passaggi che lo sviluppatore esegue per ogni nuova funzionalità. Questo processo riduce al minimo i conflitti di unione e garantisce il controllo qualità del codice.

1. Creazione del ramo dall'ultimo commit di develop. Lo sviluppatore passa a develop, lo aggiorna e crea un nuovo ramo feature.
2. Sviluppo e commit nel ramo feature. Lo sviluppatore apporta modifiche, esegue commit con descrizioni chiare e invia periodicamente il ramo al repository remoto.
3. Sincronizzazione con develop — durante lo sviluppo, il ramo principale potrebbe avanzare. Lo sviluppatore esegue un rebase o merge di develop nel proprio ramo feature.
4. Creazione di una Pull Request — quando la funzionalità è pronta, lo sviluppatore apre una PR per la revisione del codice. Il team esamina il codice e lascia commenti.
5. Unione ed eliminazione — dopo l'approvazione della PR, il ramo viene unito a develop ed eliminato sia localmente che in remoto.

La sincronizzazione periodica con develop è di fondamentale importanza. Più a lungo un ramo feature vive senza unire le modifiche da develop, maggiore è la probabilità di conflitti durante l'unione finale.

Frequenza di sincronizzazione del ramo feature

Regole di denominazione dei rami feature

La denominazione dei rami è una parte importante della disciplina di squadra. Uno standard di denominazione uniforme consente di identificare rapidamente su quale attività si sta lavorando e chi la sta eseguendo.

• feature/nome — il prefisso feature/ viene utilizzato nel Git Flow classico. Esempio: feature/added-auth-module.
• feature/JIRA-123-descrizione — collegamento al numero dell'attività nel sistema di tracciamento. Esempio: feature/PROJ-42-add-login.
• feature/tipo/nome — formato esteso con indicazione del tipo di attività. Esempio: feature/feat/analytics-dashboard.

L'uso dell'ID attività da JIRA, Trello o un altro sistema è una best practice. Collega automaticamente il codice all'attività e semplifica la ricerca dei rami tramite git log.

Processo di Pull Request

Pull Request (o Merge Request in GitLab) è una richiesta di unire il ramo feature in develop. Una PR non è solo un'operazione tecnica, ma un processo di revisione del codice di squadra che migliora la qualità del codice e diffonde la conoscenza all'interno del team.

Una buona PR contiene un titolo con una breve descrizione dell'attività, un link al ticket e una descrizione delle modifiche. Lo sviluppatore deve indicare cosa è stato fatto esattamente, quali file sono stati modificati e se ci sono potenziali rischi per altre parti del progetto.

Il team esamina il codice nella PR, lascia commenti, richiede modifiche (change requests) e approva l'unione (approve). Dopo l'approvazione, viene eseguito un merge o squash merge.

Il tempo medio di revisione di una PR nello sviluppo mobile va da 4 a 24 ore. La libreria Danger automatizza parte dei controlli, eseguendo linters e test direttamente nella PR.

Consigli per creare una buona PR

• Dimensione — non più di 300-400 righe di modifiche. PR grandi sono difficili da revisionare e la qualità della revisione diminuisce.
• Una PR — un'attività — evitate di mescolare modifiche non correlate in una singola richiesta.
• Screenshot — per modifiche all'interfaccia, allegate screenshot prima e dopo.
• Test — per nuove funzionalità, scrivete test unitari e includeteli nella PR.

Strategie di unione dei rami feature

Dopo l'approvazione della PR, il ramo feature può essere unito a develop in diversi modi. La scelta della strategia di unione influisce sulla cronologia dei commit e sulla possibilità di annullare le modifiche.

• Merge commit — crea un commit di unione, preservando l'intera cronologia dei commit del ramo feature. La cronologia rimane completa, ma il grafo di branching diventa più complesso.
• Squash merge — combina tutti i commit del ramo feature in uno solo e lo aggiunge sopra develop. La cronologia diventa più pulita, ma le informazioni sui commit intermedi vengono perse.
• Rebase and merge — riscrive i commit del ramo feature sopra l'ultimo commit di develop e unisce senza un commit aggiuntivo. La cronologia rimane lineare.

Per progetti mobili con rilasci frequenti, il squash merge è il più utilizzato: fornisce una cronologia pulita in develop, mentre i dettagli dello sviluppo rimangono nella descrizione della PR e nell'attività del tracker.

Errori tipici nell'uso di Feature Branch

Anche gli sviluppatori esperti commettono errori quando lavorano con i rami feature. Conoscere i problemi tipici aiuta a evitare perdite di tempo e dati.

• Vita troppo lunga del ramo — un ramo feature vive più di 2-3 settimane senza sincronizzazione con develop, portando a conflitti di unione massicci.
• Commit con descrizioni poco chiare — messaggi come “fix” o “update” non spiegano cosa è stato modificato e perché.
• Miscuglio di attività — nello stesso ramo feature vengono sviluppate due funzionalità non correlate, rendendo impossibile l'annullamento selettivo.
• Mancanza di sincronizzazione — lo sviluppatore non esegue git fetch e non aggiorna develop, causando conflitti durante l'unione finale.

Il modo migliore per evitare questi problemi è concordare le regole di lavoro all'inizio del progetto e utilizzare controlli automatizzati nella pipeline CI/CD.

Esempi di comandi per lavorare con Feature Branch

Consideriamo uno scenario pratico: uno sviluppatore inizia una nuova funzionalità di autenticazione in un'applicazione mobile. Crea un ramo feature, lavora sul codice e completa l'attività con una Pull Request.

# Aggiornare develop e creare il ramo feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Lavoro sulla funzionalità: commit
git add src/ui/login/
git commit -m "Add login screen layout"

# Inviare il ramo feature al server remoto
git push origin feature/add-login-screen

# Sincronizzazione con develop (rebase)
git fetch origin develop
git rebase origin/develop

# Dopo l'approvazione della PR: aggiornare develop locale ed eliminare il ramo
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Il comando git branch -d elimina il ramo solo dopo che le sue modifiche sono state completamente unite. Se il ramo non è stato unito, Git suggerirà di usare git branch -D per l'eliminazione forzata — usate questo flag con cautela.

Automazione dei controlli nel ramo feature

La pipeline CI/CD dovrebbe essere eseguita per ogni ramo feature prima di creare una PR. Ciò consente di rilevare i problemi in una fase precoce, prima che il codice arrivi alla revisione di altri sviluppatori.

# GitHub Actions per verificare il ramo feature
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

La pipeline verifica che il codice compili, i test superino e lo stile del codice sia conforme agli standard del team. Solo dopo aver superato tutti i controlli è possibile creare una Pull Request.