Introduction aux différents modèles de branches et de leurs cas d'usage

1. 15 février 2018
GIT
FLOWS

2. UN PEU D’HISTOIRE
2

3. 3
UN PEU D’HISTOIRE
QUIZZ
QUI A INVENTÉ GIT ?
QUAND ?
POURQUOI ?
GIT CA VEUT DIRE QUOI ?

4. 4
GROSSES DIFFERENCES AVEC SUBVERSION
1. A LA BASE CA N’EST PAS UN VCS
2. DÉCENTRALISÉ
 ON PEUT BOSSER EN LOCAL SANS INTERNET !
 CRÉER DES BRANCHES SANS LES POUSSER
 ETC…
3. PAS DE MODÈLE DE BRANCHE PRÉÉTABLI
 LIBERTÉ TOTALE DE WORKFLOW !

5. MODÈLES DE BRANCHE
5

6. 6
POURQUOI UTILISER UN MODÈLE DE BRANCHE ?
?

7. 7
POURQUOI UTILISER UN MODÈLE DE BRANCHE ?

8. 8
POURQUOI UTILISER UN MODÈLE DE BRANCHE ?

9. 9
POURQUOI UTILISER UN MODÈLE DE BRANCHE ?

10. 10
POURQUOI UTILISER UN MODÈLE DE BRANCHE ?

11. NO-FLOW
11

12. GITFLOW
12

13. 13
GITFLOW
EXPOSÉ EN 2010 PAR VINCENT DRIESSEN
« A SUCCESSFUL GIT BRANCHING
MODEL »
HTTP://NVIE.COM/POSTS/A-SUCCESSFUL-GIT-BRANCHING-
MODEL/

14. 14
GITFLOW BRANCHES
1. BRANCHES PRINCIPALES :
 MASTER EST LA BRANCHE OÙ TOUT EST STABLE. CHAQUE COMMIT CORRESPOND À UNE
VERSION STABLE DU PROJET (RELEASE) QUI PEUT ÊTRE DÉPLOYÉE EN PRODUCTION ET
TAGUÉE EN CONSÉQUENCE (VX.Y.Z).
 DEVELOP EST LA BRANCHE SUR LAQUELLE S’EFFECTUE LE DÉVELOPPEMENT
PROPREMENT DIT. ON Y PRÉPARE LES CHANGEMENTS EN VUE DE LA PROCHAINE
RELEASE DANS MASTER.
2. BRANCHES SECONDAIRES :
 FEATURE PART DE DEVELOP ET SE MERGE DANS DEVELOP.
 RELEASE PART DE DEVELOP ET SE MERGE DANS MASTER ET DEVELOP.
 HOTFIX PART DE MASTER ET SE MERGE DANS MASTER ET DEVELOP OU RELEASE (SI
ELLE EXISTE).

15. 15
GITFLOW SCHEMA

16. GITHUB FLOW
16

17. 17
GITHUB FLOW
CRÉÉ PAR SCOTT CHACON EN 2011 CAR :
• GITHUB DÉPLOIE « TOUT LE TEMPS »
• ILS N’ONT PAS DE « RELEASE »
6 RÈGLES
 TOUT CE QUI EST DANS MASTER PEUT ÊTRE DÉPLOYÉ EN PRODUCTION
 CRÉER DES BRANCHES EXPLICITES DEPUIS MASTER (FEATURES)
 POUSSER SUR ORIGIN RÉGULIÈREMENT
 OUVRIR UNE PULL-REQUEST À TOUT MOMENT
 FUSIONNER SEULEMENT APRÈS UNE PULL-REQUEST REVIEW
 DÉPLOYER IMMÉDIATEMENT APRÈS MERGE DANS MASTER

18. 18
GITHUB FLOW
AVANTAGES / INCONVENIENTS
 PAS VRAIMENT DE VERSION
 FORTEMENT BASÉ SUR LES PULLS REQUESTS
 PERMET D’INTRODUIRE PEU DE BUGS SIMULTANÉMENT ET DE LES CORRIGER
RAPIDEMENT.
 ADAPTÉ AU CD, AUX FEATURES TEAM
 NÉCESSITE DES TESTS AUTOMATISÉS ET UNE PROCÉDURE DE ROLLBACK DE VERSION

19. GITLAB FLOW
19

20. 20
GITLAB FLOW
ENSEMBLE DE 11 BEST PRACTICES
 USE FEATURE BRANCHES, NO DIRECT COMMITS ON MASTER.
 TEST ALL COMMITS, NOT ONLY ONES ON MASTER.
 RUN ALL THE TESTS ON ALL COMMITS (IF YOUR TESTS RUN LONGER THAN 5 MINUTES
HAVE THEM RUN IN PARALLEL).
 PERFORM CODE REVIEWS BEFORE MERGES INTO MASTER, NOT AFTERWARDS.
 DEPLOYMENTS ARE AUTOMATIC, BASED ON BRANCHES OR TAGS.
 TAGS ARE SET BY THE USER, NOT BY CI.
 RELEASES ARE BASED ON TAGS.
 PUSHED COMMITS ARE NEVER REBASED.
 EVERYONE STARTS FROM MASTER, AND TARGETS MASTER.
 FIX BUGS IN MASTER FIRST AND RELEASE BRANCHES SECOND.
 COMMIT MESSAGES REFLECT INTENT.

21. 21
GITLAB FLOW

22. SEMVER
22

23. 23
SEMANTIC VERSIONING
TOM PRESTON-WERNER (GRAVATARS, GITHUB).
MAJOR.MINOR.PATCH
 MAJOR VERSION WHEN YOU MAKE INCOMPATIBLE API CHANGES,
 MINOR VERSION WHEN YOU ADD FUNCTIONALITY IN A BACKWARDS-COMPATIBLE
MANNER
 PATCH VERSION WHEN YOU MAKE BACKWARDS-COMPATIBLE BUG FIXES.
VERSIONS PARTICULIÈRES :
 0.1.0 : PREMIÈRE VERSION DE DEV
 1.0.0 : PREMIÈRE VERSION EN PRODUCTION
 100.0.0 : IMPOSSIBLE CAR IL NE FAUT PAS CASSER L’API TROP FRÉQUEMMENT.

24. BONUS :
REBASE OR
NOT REBASE ?
24

25. 25
REBASE OR NOT REBASE ?

26. Q&A
26