T'es plutôt git merge ou git rebase ?
Jean Detoeuf
Développeur freelance
Logo upcoding
LyonTechHub
ScalaIO
Software Crafter
DDD
Agile
Git malgré lui
Mettre une photo d'un merge hell
- Bullet One
- Bullet Two
- Bullet Three
Mettre une photo d'un joli historique
Subtitle
Merge
Mettre une image de merge depuis la doc officielle
Rebase
Mettre une image de rebase depuis la doc officielle
Eviter les conflits de merge
-
Connaissance de l’historique
-
Faire des branches courtes
-
Sur des parties indépendantes (ce qui est le cas si on est sur des stories différentes et qu’on a suivi les principes clean code)
Eviter les conflits de rebase
-
utiliser rerere pour se souvenir de la résolution de conflit
-
Ou si on peut se le permettre, squasher les commits de la branche
Stratégies de branches
- Simple
- git flow
- Branche unique
git flow
Pourquoi soigner son historique
-
Lisibilité du log
-
Simplifier les recherches archéologiques à la git blame
-
Possibilité de générer un changelog
-
Indiquer dans les Pull Request les différents éléments à relire indépendamment
Dans quels cas utiliser le merge ?
-
Pour les branches persistantes (master, dev, prod, …) en mode fast-forward
-
Quand on veut grouper des commits au sein d’une même fonctionnalité sans les squasher
Dans quels cas utiliser le rebase ?
-
Pour les branches locales, le pull --rebase devrait être la norme (git config --global branch.autoSetupRebase always)
-
Pour nettoyer son historique et se mettre à jour
Les mauvaises pratiques du merge
-
Merger le remote dans le local !
-
Ne pas nettoyer ses commits avant de merger
Merci
Questions ?
T'es
By Jean Detoeuf
T'es
- 187