Come avviene l'unione dei rami (merge) o la riscrittura della storia (rebase) nel sistema di controllo versione della vostra azienda?

Nel nostro team seguiamo un flusso di lavoro basato su Git. Per integrare le modifiche, utilizziamo due approcci principali: merge e rebase, scegliendoli in base alla situazione e al tipo di branch.

Merge:

• Viene generalmente applicato per unire branch di lunga durata, ad esempio dev in main, o per integrare branch di funzionalità in dev.
• Crea un commit di merge che mostra chiaramente quando si è verificata l'integrazione delle modifiche da altri branch.
• Mantiene tutta la storia dei commit, comprese tutte le biforcazioni.

git checkout dev  // Passa al branch di destinazione
git merge feature/nuova-funzionalità  // Esegue il merge del branch di funzionalità

Rebase:

• Viene usato per mantenere una storia pulita e lineare nei branch di funzionalità fino alla loro integrazione (di solito in dev).
• Trasferisce i commit del branch corrente sulla cima del branch di destinazione (dev), riscrivendo effettivamente la storia.
• Semplifica la storia, evitando commit di merge per ogni piccola funzionalità o correzione.
• Importante: Non fare mai rebase su branch pubblici su cui lavorano altri sviluppatori, poiché ciò può creare conflitti al pull delle modifiche.

git checkout feature/nuova-funzionalità  // Passa al branch di funzionalità
git rebase dev  // Trasferisce i commit del branch di funzionalità sulla cima di dev
// Risolvi eventuali conflitti se necessario
git push --force-with-lease  // Usa --force-with-lease per un push sicuro dopo il rebase

Il nostro flusso di lavoro standard:

1. Una nuova funzionalità o correzione viene sviluppata in un branch separato (feature/..., fix/...).
2. Periodicamente (prima di una pull request o per sincronizzarsi con dev), il branch di funzionalità viene rebaseato sulla versione attuale di dev. Questo aiuta a risolvere i conflitti in una fase precoce.
3. Dopo aver completato lo sviluppo e la revisione del codice, il branch di funzionalità viene fuso in dev con no-ff (non fast-forward), per mantenere le informazioni sulla fusione. Oppure, meno frequentemente, viene fatto uno squash in un singolo commit prima di fondere in dev per modifiche molto piccole o correzioni.
4. Da dev, vengono rilasciate versioni periodiche in main (branch di produzione), sempre tramite merge.

In questo modo, bilanciamo la conservazione della storia dei commit (merge) con il mantenimento di un branch di sviluppo pulito (rebase dei branch di funzionalità).