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 ?