git++
Passez au niveau supérieur
de la gestion de version
1. Une conviction
2. Une méthode
3. Des outils
Améliorer la qualité
1. Une conviction 2. Une méthode 3. Des outils => Améliorer la qualité Qui utilise git ? Qui a trouvé git complexe au début ?
man git (>_<)
git != SVN
git, un outil multi-fonction!
git, une arme pour les NINJAS!
git va nous permettre de combattre un fléau trop répandu: L'historique sale :-(
Un historique
sale
Un historique sale
Un historique
propre
Mais pourquoi faire ?
Dans quels cas de figure il est utile/indispensable d'avoir un historique propre ?
Perte de mémoire
Mais à quoi elle sert cette méthode déjà ? Pourquoi je l'ai ajouté avec cette visibilité ?
En cas d'absence
Vacances, réunions, arrêt maladie, formations, devoxx... toutes ces raisons qui peuvent empêcher de contacter vos collègues ou qui peuvent empêcher vos collègues de vous contacter.
Arrivée d'un nouveau
Quand on doit accueillir un petit nouveau, c'est encore plus utile pour lui de pouvoir comprendre l'histoire de votre produit.
Revue de code
C'est pour toutes ces raisons que c'est important de donner du sens à notre historique de code!
Donnons du sens à notre
historique
Conventions de commit
Conventions de commit
Quoi ? Où ? (Pour)quoi ? Comment ? Référence ?
Conventions de commit
Conventions de commit
feat : fonctionnalité fix : correctif refactor : changement technique chore : changement build/config test : test manquant docs : changement dans la documentation style : changement de formattage
Conventions de commit
(optionnel) Listez vos scopes Faites les évoluer dans le temps
Conventions de commit
Description des changements Point de vue utilisateur (feat, fix)
Conventions de commit
(optionnel) Détails sur le sujet Détails d'implémentation
Conventions de commit
(optionnel) Identifiant de bug fix Identifiant de user story
Exemple : une fonctionnalité
Exemple : une correction
Des développeurs contents
C'est que pour les dév ?
Générer un
changelog
Des utilisateurs contents
Un Product Owner content
Améliorons notre
historique
Savoir manipuler des commits :
Renommer
Modifier
Réordonner
Fusionner
Insérer
Supprimer
On peut se tromper dans nos commits et notre code peut évoluer au fil du temps, il faut être capable de modeler nos commits comme on l'entend...
git rebase -i
WAT ??
git merge
Il faut comprendre les différences entre les stratégie merge et rebase
Je suis sur la branche feature...
...et master a évolué.
git merge
Je continue sur ma branche feature...
...et master a évolué.
git merge
git merge mal utilisé
git rebase
Master a évolué.
git rebase (pendant)
git rebase (après)
Master a évolué.
git rebase (pendant)
git rebase (après)
git merge vs. git rebase
On vous propose 2 options, elles font débat partout et souvent, et son sujet à troll. Une option où l'historique est trouble et chaotique et une autre où l'historique est clair et lisible!
git rebase FTW !
historique simple
perte du contexte de travail
plus difficile à maitriser
historique simple perte du contexte de travail plus difficile à maitriser
git merge vs.
git rebase
attention aux rebases
de commits partagés
git rebase -i ?
Je suis sur la branche feature...
Je choisis le commit à éditer.
git rembobine dessus.
J'édite mon code.
git rejoue le reste de l'historique...
...et replace ma branche.
Et voilà : "ni vu, ni connu".
git rebase ?
git commit ?
ou git merge ?
Je prends une US dans le backlog.
Je créé une branche depuis master.
Je refactor une méthode.
J'implémente la fonctionnalité.
J'ai une autre idée pour le refactor.
Je fusionne les étapes de conception...
...avec un git rebase interactive.
Pendant ce temps là, master évolue.
Je me rebase sur la dernière version.
Je soumets ma pull request.
J'attire l'attention de l'équipe.
L'équipe fait
une revue de code.
Remarque : il manque un cas de test.
Si les tests sont verts,
l'équipe rajoute des gifs.
Automatisation du workflow business process CMMI v12 !
Je prends en compte la remarque.
L'équipe valide mes changements.
Je fusionne les étapes de la revue...
...avec un git rebase interactive.
L'équipe merge la branche.
La fonctionnalité est dans le produit.
git rebase, git commit ou git merge ?
  1. Code privé➜ rebase
  2. Code review➜ commit
  3. Code ready➜ rebase
  4. Code merge➜ merge
Code privé ➜ rebase et rebase -i Code review ➜ commit Code ready ➜ rebase Code merge ➜ merge
démo
git++
Ce qu'il faut retenir
1
Une conviction
Un historique propre
Un historique propre c'est important, pour avoir : Qualité dans le code Sérénité dans l'équipe Valeur pour l'utilisateur
2
Une méthode
Conventions de commit
git merge vs. git rebase
3
Des outils
git rebase -i
Renommer
Modifier
Réordonner
Fusionner
Insérer
Supprimer
npm i grunt-conventional-changelog
grunt changelog
Merci !!
Cyril
LAKECH
@cyril_lakech
@chtijug
Hubert
SABLONNIÈRE
@hsablonniere
bit.ly/gitplusplus