Il documento discute le pratiche di gestione dei branch in Git, evidenziando l'importanza di organizzare i branch per facilitare lo sviluppo simultaneo e il deploy senza problemi. Presenta diversi modelli di branching, come Git Flow e alternative più semplici come 'issue-flow', e fornisce consigli e regole per una gestione efficace. Indica quale metodo adottare in base alla tipologia di progetto e al team coinvolto.

1. 1

2. Chi sono
● eCommerce Backend Developer (Sylius, Shopware, ex Magento Developer)
● Node.js newbie
● DevOps se necessario
● Membro e speaker del PUG Romagna
2

3. Index
Git branching model
● Perchè organizzare i branches git
● Git flow
● Alternative al git flow
● Quale metodo usare in base al
team/progetto/deploy
● Le 10 regole da ricordare
3

4. Perchè organizzare
i branches git
●
4

5. Perchè organizzare
i branches git
● Facilità nella gestione degli sviluppi in
contemporanea
● Evitare problemi con il deploy
● Avere un sistema per ricostruire la
storia del codice tramite un sistema di
gestione progetti
● Evitare di fare il merge di branches non
legati al proprio task/feature
● Versione semplice: “evitare casini”
5

6. Git flow
● 2 branches principali: master main e
develop
● convenzioni nomi branch:
○ feature -> nuove funzionalità
○ hotfix -> bugfixing
○ release -> testing pre-pubblicazione
● Possibilità di usare “client” per gestire in
maniera autonoma la gestione dei branches
6

7. Git flow
Credits: Vincent Driessen
https://nvie.com/posts/a-successfu
l-git-branching-model/
●
7

8. Git flow
PRO
● Possibilità di gestire i permessi dei
branches
● Evitare di fare commit dirette su
develop o master main
● Facilità di rollback in caso di problemi
grazie ai tag delle releases
● Il team ha regole ben precise nella
creazione del branch o pubblicazione
8

9. Git flow
CONTRO
● Non del tutto adatto a progetti con
Continuous Delivery tipo e-commerce
● Molto “macchinoso” per progetti
semplici e con team “piccolo”
● Tutti i nuovi branches partono da
develop, quindi pubblicare features in
ordine “sparso” può essere un problema
9

10. Alternative al git
flow
“git-flow semplificato”
● I nuovi branches partono da master main e
non develop
● Esistono solo 2 tipologie di branches:
- feature
- hotfix
● Feature branch viene mergiato sia in
develop che master main
● Hotfix branch viene mergiato solo in master
main
● Develop viene allineato con master main
● Non ci sono tag
10

11. Alternative al git
flow
“git-flow semplificato”
●
11

12. Alternative al git
flow
“issue-flow”
● I branches principali sono strettamente
legati all’ambiente dove viene deployato il
codice:
- master main -> produzione
- develop -> staging
- test -> testing (se esiste)
● Non si dovrebbe committare direttamente
in un branch principale (solo merge o pull
request da issue branches)
● Tutti i nuovi branches sono creati sempre da
master main e sono chiamati
issue-<identificativo task>
12

13. Alternative al git
flow
“issue-flow”
● Un issue branch può essere mergiato in
develop o test ma non è detto che venga
mergiato in master main (es. task non più
approvato)
● Un issue branch prima di essere mergiato in
master main deve essere riallineato per non
essere “troppo indietro”
● Nel caso in cui in develop ci siano troppi
branches non approvati, esso può essere
distrutto e ricreato da master main
13

14. Alternative
al git flow
“issue-flow”
●
14

15. Alternative
al git flow
“issue-flow”
●
15

16. Quale metodo
usare in base al
team / progetto /
deploy
TEAM
INDIFFERENTE
Anche lavorando da solo è necessario
darsi delle regole / specifiche
16

17. Quale metodo
usare in base al
team / progetto /
deploy
PROGETTO
● Progetti con Continuous Delivery:
issue-flow
● Per “Prodotti”: git-flow
● Per “Piccole applicazioni”: issue-flow o
git-flow semplificato
17

18. Quale metodo
usare in base al
team / progetto /
deploy
DEPLOY
● Progetti con Ambienti multipli: issue-flow o
git-flow semplificato
● Per “Prodotti” quindi no ambienti di test
online: git-flow
18

19. Le 10 regole da
ricordare
1. Avere sempre un software di gestione
progetti da affiancare al git
2. Testare tutte le commit non solo al momento
prima del merge
3. Il merge dei branches va fatto con le
pull/merge request e non in locale con ‘git
merge’
4. Il tag va impostato da una persona e non
dalla CI (pipeline)
5. Le commit sono sempre associate ad un task
(quindi inserire nel commento un id task)
19

20. Le 10 regole da
ricordare
6. Le commit seguono uno schema. Scrivere
“fixed” non aiuta
7. Le commit spiegano l’intento e non ciò che è
stato fatto
8. I changelog automatizzati con i testi delle
commit non servono a nulla ( usa
keepachangelog.com )
9. Evitare le commit dirette nei branches
“principali”
10. Non cancellare mai i branches (possono
essere utili come backup)
20

21. Grazie!
Domande?
Twitter: @giuseppemorelli
Github: github.com/giuseppemorelli
web: giuseppemorelli.net
21