Develop Branch in Git — cos'è, scopo e principi di funzionamento

Cos'è Develop Branch in Git

Develop Branch (ramo di sviluppo) è un ramo di lunga durata in Git Flow che funge da hub centrale per l'integrazione del codice di tutti gli sviluppatori. I rami feature vengono mergeati in esso dopo il completamento dello sviluppo e la revisione del codice.

Il codice in develop è sempre in uno stato pronto per creare un rilascio, anche se non ancora distribuito in produzione. Ciò significa che tutte le funzionalità in develop hanno superato revisione, test e controlli di integrazione, ma stanno ancora aspettando il loro ciclo di rilascio.

A differenza di main, dove ogni versione del codice è un rilascio, develop contiene un flusso continuo di modifiche. I commit in develop appaiono man mano che i rami feature vengono mergeati, cosa che può accadere più volte al giorno.

Secondo Vincent Driessen, 2010, develop è un elemento chiave di un modello di branching di successo, poiché separa il lavoro in bozza dalle versioni pronte per il rilascio.

Differenze tra develop e main branch

Comprendere le differenze tra develop e main è fondamentale per un corretto flusso di lavoro Git Flow. Questi rami svolgono funzioni diverse e hanno diversi requisiti di stabilità.

La separazione in develop e main consente al team di integrare continuamente nuovo codice senza rischiare la stabilità della versione di produzione. Gli sviluppatori possono vedere il proprio codice in develop subito dopo l'approvazione del PR, anche prima del rilascio ufficiale.

Ruolo di develop in Git Flow

Nel modello Git Flow, develop occupa una posizione centrale tra i rami feature (fonte delle modifiche) e i rami release (preparazione al rilascio). Comprendere questa gerarchia è la base per un branching efficace.

• Feature → Develop — ogni funzionalità completata viene mergeata in develop tramite Pull Request con revisione del codice.
• Develop → Release — quando si accumulano abbastanza modifiche per un rilascio, viene creato un ramo release da develop.
• Release → Main + Develop — dopo la preparazione finale, il ramo release viene mergeato in main (rilascio) e di nuovo in develop (correzioni di bug).
• Hotfix → Main + Develop — le correzioni critiche vengono create da main e mergeate in entrambi i rami.

Questa struttura garantisce che develop contenga sempre il codice più recente con tutte le nuove funzionalità, mentre main contiene solo codice di produzione verificato. Questo è particolarmente importante per i progetti mobili con lunghi cicli di revisione nell'App Store e Google Play.

Relazione di develop con altri rami Git Flow

Develop funge da collegamento centrale tra i rami feature, release e hotfix. Comprendere le direzioni di merge è essenziale per prevenire conflitti e perdita di commit.

Requisiti di qualità del codice in develop

La qualità del codice in develop deve essere elevata, ma non assoluta. A differenza di main, dove ogni errore significa un hotfix urgente, develop permette imperfezioni minori che verranno corrette prima del rilascio.

Requisiti minimi per il codice prima del merge in develop:

• Compilazione — il codice deve compilare senza errori. Una build rotta in develop blocca il lavoro dell'intero team.
• Test unitari — tutti i test esistenti devono superare. Il nuovo codice deve essere coperto da test almeno al 70%.
• Stile del codice — il codice deve essere conforme agli standard di formattazione e denominazione accettati dal team.
• Nessuna API deprecata — l'uso di metodi deprecati non è consentito nel nuovo codice.

I controlli automatizzati nella pipeline CI/CD devono essere eseguiti ad ogni push in develop. Se la build si rompe, lo sviluppatore responsabile deve risolvere il problema entro un'ora o annullare il proprio commit.

Controlli CI/CD per develop

L'impostazione di GitHub Actions per develop garantisce che ogni PR passi attraverso controlli automatizzati prima del merge. Una pipeline tipica include build, test e linting.

# GitHub Actions — verifica di develop dopo il merge
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Regole di merge in develop

Il merge in develop deve seguire regole rigorose per mantenere la stabilità del ramo di integrazione. La violazione di queste regole porta a conflitti, build rotte e perdita di tempo del team.

• Solo tramite Pull Request — il push diretto in develop è vietato. Tutte le modifiche passano attraverso la revisione del codice.
• Minimo un'approvazione — il PR deve essere approvato da almeno uno sviluppatore non coinvolto nell'attività.
• Squash merge — si consiglia di combinare tutti i commit del ramo feature in uno solo durante il merge in develop per una cronologia pulita.
• PR aggiornato — prima del merge, il PR deve essere aggiornato rispetto all'ultimo commit di develop (rebase o merge).

La regola del PR aggiornato è particolarmente importante. Se un ramo feature è stato creato una settimana fa e develop è avanzato di 50 commit, il merge diretto potrebbe causare conflitti che è meglio risolvere nel contesto del PR piuttosto che in develop.

Proteggere develop da merge errati

Le regole di protezione del ramo sono impostazioni a livello di GitHub, GitLab o Bitbucket che impediscono modifiche errate in develop. Garantiscono che anche un push accidentale non rompa il ramo di integrazione.

Regole di protezione consigliate per develop:

• Richiedi pull request — vietare il push diretto in develop. Tutte le modifiche solo tramite PR.
• Richiedi approvazioni — minimo 1-2 approvazioni prima del merge del PR.
• Richiedi controlli di stato — bloccare il merge se la pipeline CI/CD non è stata superata.
• Richiedi aggiornamento — il ramo del PR deve essere aggiornato rispetto a develop prima del merge.
• Limita accesso push — limitare i diritti di push in develop solo agli sviluppatori senior.

L'impostazione della protezione di develop richiede 10 minuti ma previene settimane di inattività legate a un ramo di integrazione rotto. Per i progetti mobili con team multipiattaforma, questo è particolarmente rilevante.

Esempi di comandi per lavorare con develop

Consideriamo una giornata tipica di uno sviluppatore: la mattina aggiorna develop, crea un nuovo ramo feature e, dopo aver completato l'attività, mergea le modifiche in develop.

# Sincronizzazione mattutina di develop
git checkout develop
git pull origin develop

# Creazione di un nuovo ramo feature da develop
git checkout -b feature/add-push-notifications

# Lavorando sulla funzionalità...
git add . && git commit -m "Add FCM integration"

# Aggiornamento di develop durante lo sviluppo
git fetch origin develop
git rebase origin/develop

# Dopo l'approvazione del PR — aggiornare develop locale
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Il comando git pull in develop esegue due operazioni contemporaneamente: git fetch (recupera nuovi commit dal server) e git merge (li fonde con il ramo locale). Per develop, questo è il metodo di sincronizzazione standard.

Ripristino di develop dopo un merge rotto

Se il codice che ha rotto la build entra in develop, bisogna agire rapidamente. Ogni ora di inattività di develop è lavoro bloccato per l'intero team di sviluppo.

Se il codice che ha rotto la build entra in develop, usa git revert per creare un nuovo commit che annulla le modifiche problematiche. Non usare git reset in develop — riscrive la cronologia che altri membri del team già possiedono.

# Trovare il commit problematico
git log --oneline develop

# Annullamento del commit tramite revert (sicuro)
git revert a1b2c3d

# Invio della correzione a develop remoto
git push origin develop

# Visualizzare le modifiche in un commit specifico
git show a1b2c3d --stat