Successfully reported this slideshow.
Your SlideShare is downloading. ×

Git branching model

Ad

1

Ad

Chi sono
● eCommerce Backend Developer (Sylius, Shopware, ex Magento Developer)
● Node.js newbie
● DevOps se necessario
● ...

Ad

Index
Git branching model
● Perchè organizzare i branches git
● Git flow
● Alternative al git flow
● Quale metodo usare in b...

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Upcoming SlideShare
Ttg 09 07_2015_debug_vs_2015
Ttg 09 07_2015_debug_vs_2015
Loading in …3
×

Check these out next

1 of 21 Ad
1 of 21 Ad
Advertisement

More Related Content

Advertisement

Git branching model

  1. 1. 1
  2. 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. 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. 4. Perchè organizzare i branches git ● 4
  5. 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. 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. 7. Git flow Credits: Vincent Driessen https://nvie.com/posts/a-successfu l-git-branching-model/ ● 7
  8. 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. 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. 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. 11. Alternative al git flow “git-flow semplificato” ● 11
  12. 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. 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. 14. Alternative al git flow “issue-flow” ● 14
  15. 15. Alternative al git flow “issue-flow” ● 15
  16. 16. Quale metodo usare in base al team / progetto / deploy TEAM INDIFFERENTE Anche lavorando da solo è necessario darsi delle regole / specifiche 16
  17. 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. 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. 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. 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. 21. Grazie! Domande? Twitter: @giuseppemorelli Github: github.com/giuseppemorelli web: giuseppemorelli.net 21

×