- Vuoi mantenere la cronologia dei tuoi branch pulita ed efficace?
- Fai parte di un team di sviluppo di almeno 4-5 persone e cerchi un workflow strutturato ma agile?
🕐 Tempo di lettura: 3 minuti
Nel mio team adottiamo una variante di Git Flow, con influenze dal Trunk-Based Development (TBD), ottimizzata per le metodologie Agile. Questo approccio combina organizzazione e flessibilità, migliorando il processo di sviluppo e integrazione. In questo post ti spiego la nostra strategia.
📌 Un repository Git strutturato su quattro livelli
master: contiene il codice stabile, pronto per la produzionedevelop: raccoglie le versioni candidate per l'ambiente di staging al termine dello sprintsprint: branch temporaneo usato durante un singolo ciclo di rilascio in fase di collaudofeature/fix: rami dedicati alle singole funzionalità o correzioni, integrati nel branchsprinttramite merge squash
📌 Strategia di merge
- merge da padre a figlio (
master→develop,develop→sprint,sprint→feature) - merge squash da figlio a padre, in modo da mantenere una history più pulita
- i branch
feature/fixsono staccati dal branchsprintcorrente. Prima di eseguire il merge squash versosprint, è consigliabile "portare dentro" le modifiche più recenti dal branchsprintnella propria feature, risolvendo eventuali conflitti in anticipo - al termine dello sprint, il relativo branch (
S) viene unito indeveloptramite un merge squash. Successivamente il branch dello sprint viene archiviato e dadevelopsi stacca un nuovo branch (S+1) per lo sprint successivo. I branch difeature/fixcollegati allo sprint concluso vengono eliminati, preservando così la granularità necessaria e scartando dettagli superflui
![Cronologia delle release in master con merge squash: history lineare e tag [RELEASE vX.Y.Z]](/images/articles/0011-git-history.jpeg)
📌 Vantaggi di questo flusso ibrido
- i merge da padre a figlio assicurano che i branch ereditino sempre gli ultimi aggiornamenti
- l'allineamento costante evita conflitti di grandi dimensioni alla fine dello sviluppo
- gli eventuali conflitti sono risolti nei branch figli, mantenendo pulito il branch padre
- grazie al merge squash verso il branch padre, la main history non viene appesantita da commit intermedi
- si mantiene un log più chiaro e lineare, utile per debugging e rollback in caso di necessità
- il team può lavorare parallelamente su feature indipendenti
- allineamento con l'integrazione continua (CI/CD)
- adatto sia a team che fanno rilasci frequenti (TBD), sia a chi lavora su sprint più strutturati
🔍 Conclusione
Questo modello ibrido tra Git Flow e TBD risulta particolarmente efficace in un contesto di sviluppo iterativo basato su sprint: fornisce infatti un controllo strutturato delle release e, al contempo, una gestione delle feature e delle merge strategy più snella, in linea con i principi di integrazione continua.
📩 Contattami se vuoi una guida più dettagliata!
Alla prossima pillola! ☕