SlideShare a Scribd company logo
1
Chi sono
● eCommerce Backend Developer (Sylius, Shopware, ex Magento Developer)
● Node.js newbie
● DevOps se necessario
● Membro e speaker del PUG Romagna
2
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
Perchè organizzare
i branches git
●
4
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
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
Git flow
Credits: Vincent Driessen
https://nvie.com/posts/a-successfu
l-git-branching-model/
●
7
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
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
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
Alternative al git
flow
“git-flow semplificato”
●
11
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
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
Alternative
al git flow
“issue-flow”
●
14
Alternative
al git flow
“issue-flow”
●
15
Quale metodo
usare in base al
team / progetto /
deploy
TEAM
INDIFFERENTE
Anche lavorando da solo è necessario
darsi delle regole / specifiche
16
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
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
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
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
Grazie!
Domande?
Twitter: @giuseppemorelli
Github: github.com/giuseppemorelli
web: giuseppemorelli.net
21

More Related Content

Similar to Git branching model

Strumenti di automazione in Magento 2
Strumenti di automazione in Magento 2Strumenti di automazione in Magento 2
Strumenti di automazione in Magento 2
MageSpecialist
 
Git e GitHub
Git e GitHubGit e GitHub
Git e GitHub
sscalabrino
 
Git Flow - Un modello di branching che funziona
Git Flow - Un modello di branching che funzionaGit Flow - Un modello di branching che funziona
Git Flow - Un modello di branching che funzionaInnoteam Srl
 
CI/CD - Presentazione Introduttiva
CI/CD - Presentazione IntroduttivaCI/CD - Presentazione Introduttiva
CI/CD - Presentazione Introduttiva
Matteo Di Carlo
 
Integrare Zend Framework in Wordpress
Integrare Zend Framework in WordpressIntegrare Zend Framework in Wordpress
Integrare Zend Framework in Wordpress
Enrico Zimuel
 
Lezione 3: Sviluppo in Extreme Programming
Lezione 3: Sviluppo in Extreme ProgrammingLezione 3: Sviluppo in Extreme Programming
Lezione 3: Sviluppo in Extreme Programming
Andrea Della Corte
 
Milano Meetup #8 - Testing & Salesforce Integration
Milano Meetup #8 - Testing & Salesforce IntegrationMilano Meetup #8 - Testing & Salesforce Integration
Milano Meetup #8 - Testing & Salesforce Integration
Gonzalo Marcos Ansoain
 
Branching & Merging strategies (with TFS)
Branching & Merging strategies (with TFS)Branching & Merging strategies (with TFS)
Branching & Merging strategies (with TFS)
Klab
 
Slide Mulesoft Meetup Milano #10.pdf
Slide Mulesoft Meetup Milano #10.pdfSlide Mulesoft Meetup Milano #10.pdf
Slide Mulesoft Meetup Milano #10.pdf
Florence Consulting
 
Framework software e Zend Framework
Framework software e Zend FrameworkFramework software e Zend Framework
Framework software e Zend Framework
Enrico Zimuel
 
node.js everywhere
node.js everywherenode.js everywhere
node.js everywhere
Valerio Coltre
 
Roma linuxday 2013 - nodejs
Roma linuxday 2013 - nodejsRoma linuxday 2013 - nodejs
Roma linuxday 2013 - nodejs
Claudio Mignanti
 
Introduzione a git
Introduzione a gitIntroduzione a git
Introduzione a git
Klab
 
Zend Framework 2
Zend Framework 2Zend Framework 2
Zend Framework 2
Enrico Zimuel
 
Git/Continuous Integration/Docker: la terna dello sviluppo moderno.
Git/Continuous Integration/Docker: la terna dello sviluppo moderno.Git/Continuous Integration/Docker: la terna dello sviluppo moderno.
Git/Continuous Integration/Docker: la terna dello sviluppo moderno.
Gerardo Di Iorio
 
Xamarin DevOps
Xamarin DevOpsXamarin DevOps
Xamarin DevOps
Nicolò Carandini
 
Introduzione a Git
Introduzione a GitIntroduzione a Git
Introduzione a Git
Alfonso Piscitelli
 
ALM Revolutions - What's new in visual studio ALM 11
ALM Revolutions - What's new in visual studio ALM 11ALM Revolutions - What's new in visual studio ALM 11
ALM Revolutions - What's new in visual studio ALM 11
DomusDotNet
 
Standard Dev Workflow
Standard Dev WorkflowStandard Dev Workflow
Standard Dev Workflow
Stefano Corallo
 
Trunk Based Development is a social matter
Trunk Based Development is a social matterTrunk Based Development is a social matter
Trunk Based Development is a social matter
Alessio Coser
 

Similar to Git branching model (20)

Strumenti di automazione in Magento 2
Strumenti di automazione in Magento 2Strumenti di automazione in Magento 2
Strumenti di automazione in Magento 2
 
Git e GitHub
Git e GitHubGit e GitHub
Git e GitHub
 
Git Flow - Un modello di branching che funziona
Git Flow - Un modello di branching che funzionaGit Flow - Un modello di branching che funziona
Git Flow - Un modello di branching che funziona
 
CI/CD - Presentazione Introduttiva
CI/CD - Presentazione IntroduttivaCI/CD - Presentazione Introduttiva
CI/CD - Presentazione Introduttiva
 
Integrare Zend Framework in Wordpress
Integrare Zend Framework in WordpressIntegrare Zend Framework in Wordpress
Integrare Zend Framework in Wordpress
 
Lezione 3: Sviluppo in Extreme Programming
Lezione 3: Sviluppo in Extreme ProgrammingLezione 3: Sviluppo in Extreme Programming
Lezione 3: Sviluppo in Extreme Programming
 
Milano Meetup #8 - Testing & Salesforce Integration
Milano Meetup #8 - Testing & Salesforce IntegrationMilano Meetup #8 - Testing & Salesforce Integration
Milano Meetup #8 - Testing & Salesforce Integration
 
Branching & Merging strategies (with TFS)
Branching & Merging strategies (with TFS)Branching & Merging strategies (with TFS)
Branching & Merging strategies (with TFS)
 
Slide Mulesoft Meetup Milano #10.pdf
Slide Mulesoft Meetup Milano #10.pdfSlide Mulesoft Meetup Milano #10.pdf
Slide Mulesoft Meetup Milano #10.pdf
 
Framework software e Zend Framework
Framework software e Zend FrameworkFramework software e Zend Framework
Framework software e Zend Framework
 
node.js everywhere
node.js everywherenode.js everywhere
node.js everywhere
 
Roma linuxday 2013 - nodejs
Roma linuxday 2013 - nodejsRoma linuxday 2013 - nodejs
Roma linuxday 2013 - nodejs
 
Introduzione a git
Introduzione a gitIntroduzione a git
Introduzione a git
 
Zend Framework 2
Zend Framework 2Zend Framework 2
Zend Framework 2
 
Git/Continuous Integration/Docker: la terna dello sviluppo moderno.
Git/Continuous Integration/Docker: la terna dello sviluppo moderno.Git/Continuous Integration/Docker: la terna dello sviluppo moderno.
Git/Continuous Integration/Docker: la terna dello sviluppo moderno.
 
Xamarin DevOps
Xamarin DevOpsXamarin DevOps
Xamarin DevOps
 
Introduzione a Git
Introduzione a GitIntroduzione a Git
Introduzione a Git
 
ALM Revolutions - What's new in visual studio ALM 11
ALM Revolutions - What's new in visual studio ALM 11ALM Revolutions - What's new in visual studio ALM 11
ALM Revolutions - What's new in visual studio ALM 11
 
Standard Dev Workflow
Standard Dev WorkflowStandard Dev Workflow
Standard Dev Workflow
 
Trunk Based Development is a social matter
Trunk Based Development is a social matterTrunk Based Development is a social matter
Trunk Based Development is a social matter
 

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 flow ● Alternative al git flow ● Quale metodo usare in base al team/progetto/deploy ● Le 10 regole da ricordare 3
  • 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
  • 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