Ah, Git Graph... Cet outil magique qui permet de visualiser l'état des branches sans avoir à naviguer dans un océan de commandes.
Amis PO et CTO, ne vous méprenez pas : vous n'avez pas besoin de devenir un expert du rebase pour comprendre pourquoi les équipes sont en stress. Un simple coup d'œil sur Git Graph et vous saurez si votre équipe est en train de livrer des fonctionnalités ou de s'embourber dans des complications inutiles.
Un CTO qui pose la question « Alors, la feature X, ça avance ? » toutes les deux heures devient rapidement insupportable. Heureusement, Git Graph permet de suivre l'avancement des développements sans perturber le lead dev. Il devient facile de repérer une branche qui traîne sans être mergée, ce qui est rarement bon signe. Cela peut indiquer qu’un développeur rencontre des difficultés, qu’une fonctionnalité est plus complexe que prévu ou qu’elle a été reléguée aux oubliettes.
Pas besoin d’être un expert Git pour tirer parti de Git Graph. D'ailleurs, si vous utilisez GitLab, GitHub ou Bitbucket, sachez que l'aspect graphique est directement intégré et permet de suivre les branches et les merges sans avoir à manipuler du code.
Cela permet aux CTO qui ne mettent pas les mains dans le code de tout de même garder une vision fine de l'avancement des développements. Il existe plusieurs outils comme VS Code avec son extension dédiée, GitKraken qui propose une interface visuelle agréable, ou encore Sourcetree pour ceux qui naviguent déjà dans l’univers Atlassian. Même en ligne de commande, une simple exécution de git log --graph --oneline --decorate --all peut donner une bonne vision de la situation, encore faut-il retenir cette suite de mots magiques.
Dans certains cas, jeter un œil à Git Graph devient indispensable. Par exemple, lorsqu'une branche semble exister depuis des semaines sans être mergée. On découvre alors un développeur qui peine en silence ou une tâche qui s’éternise. C’est aussi utile lorsqu’un projet prend une tournure artistique avec des branches qui s’entrecroisent et des merges anarchiques, rendant la compréhension du code difficile. Cela témoigne souvent d’une gestion approximative et annonce une dette technique croissante. Il arrive aussi de tomber sur un commit du vendredi soir intitulé "final commit, ça doit marcher". Cette simple ligne suffit à déclencher un signal d’alarme et à rappeler la règle d’or : on ne commit pas sous pression, encore moins à la veille du week-end.
Pour éviter que Git Graph ne devienne un champ de bataille incompréhensible, il est essentiel d’adopter quelques bonnes pratiques. Des noms de branches explicites aident à comprendre leur utilité sans effort. Un commit bien formulé vaut toujours mieux qu’une suite de "fix bug". Mergé régulièrement, le code reste propre et lisible, réduisant le risque de conflits interminables. Une convention claire permet à toute l’équipe de parler le même langage et de collaborer efficacement.
