Git branching model
- 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 鍖ow Alternative al git 鍖ow 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 鍖ow 2 branches principali: master main e develop convenzioni nomi branch: feature -> nuove funzionalit hot鍖x -> bug鍖xing release -> testing pre-pubblicazione Possibilit di usare client per gestire in maniera autonoma la gestione dei branches 6
- 7. Git 鍖ow Credits: Vincent Driessen https://nvie.com/posts/a-successfu l-git-branching-model/ 7
- 8. Git 鍖ow 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 鍖ow 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 鍖ow git-鍖ow sempli鍖cato I nuovi branches partono da master main e non develop Esistono solo 2 tipologie di branches: - feature - hot鍖x Feature branch viene mergiato sia in develop che master main Hot鍖x branch viene mergiato solo in master main Develop viene allineato con master main Non ci sono tag 10
- 11. Alternative al git 鍖ow git-鍖ow sempli鍖cato 11
- 12. Alternative al git 鍖ow issue-鍖ow I branches principali sono strettamente legati allambiente 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-<identi鍖cativo task> 12
- 13. Alternative al git 鍖ow issue-鍖ow 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
- 16. Quale metodo usare in base al team / progetto / deploy TEAM INDIFFERENTE Anche lavorando da solo 竪 necessario darsi delle regole / speci鍖che 16
- 17. Quale metodo usare in base al team / progetto / deploy PROGETTO Progetti con Continuous Delivery: issue-鍖ow Per Prodotti: git-鍖ow Per Piccole applicazioni: issue-鍖ow o git-鍖ow sempli鍖cato 17
- 18. Quale metodo usare in base al team / progetto / deploy DEPLOY Progetti con Ambienti multipli: issue-鍖ow o git-鍖ow sempli鍖cato Per Prodotti quindi no ambienti di test online: git-鍖ow 18
- 19. Le 10 regole da ricordare 1. Avere sempre un software di gestione progetti da af鍖ancare 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 鍖xed non aiuta 7. Le commit spiegano lintento 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