Un historique propre, compréhensible et utile

On va reprendre un peu les bases, parce que je te sens un peu fébrile là, et une piqûre de rappel, ça fait toujours du bien.

En tant qu’utilisateur Git, on doit développer une compétence importante : on doit savoir garder un historique public de commits propre, compréhensible et utile.

Pour ça on a recours à 5 outils principaux :

git commit --amend, pour mettre à jour notre dernier commit ;
git reset, pour retravailler les commits du haut d’une branche ;
git merge, avec ou sans le fast-foward, pour clore un travail ;
git cherry-pick, pour reporter des commits d’une branche à une autre ;
git rebase, et ses différents modes, pour mettre à jour et nettoyer notre historique.

Je ne rentre pas dans le détail de toutes ces commandes car ça n’est pas le sujet de ce cours. Pour les commandes git commit --amend et git reset tu peux toujours aller voir notre cours « "Git undo" ou le savoir-défaire », ça risque de te servir pas mal. Dans l’immédiat je me concentre sur merge, cherry-pick et rebase.

Je me permets un apparté rapide au sujet de merge et rebase. Je vois très souvent les gens mettre ces deux commandes dans le même panier, prétextant qu’elles aboutissent au même résultat, à savoir « avoir les commits d’en face ramenés sur la branche courante ». Donc ça c’est faux, ce qu’on va voir dans ce cours. Et pire, on voit plétore d’articles, de tweets et posts sur StackOverflow et compagnie qui encouragent à ne pas utiliser rebase 😤, comme si cette commande était une mauvaise idée.

Les personnes qui ont écrit ce genre de « recommandations » ont, à mon avis, un vision étriquée et une compréhension incomplète du potentiel de rebase. C’est ce qui arrive quand on a pas lu la doc jusqu’au bout ! Donc si tu as par un malheureux hasard lu ce genre de contenu, fais-moi plaisir, fais table rase de ces informations et fais-toi ton propre avis.

Allez, on retourne à nos moutons et on va voir les rôles respectifs de merge et de rebase et je vais tenter de te donner quelques réflexes et bonnes pratiques pour que tu puisses toujours produire un historique public qui soit à la fois expressif, c'est-à-dire concis mais clair, et dont la visualisation de l’historique reflète les objectifs de l’équipe de façon optimale.

Tu verras qu’un historique nickel a une vraie valeur ajoutée pour toi comme pour ton équipe, qu’il s’agisse de contributeurs, de chefs de projet, ou encore d’autres intervenants.