Quand on code seul sur un projet personnel, Git devient vite un simple historique de sauvegarde. On commit quand on y pense, on pousse sur main, on ne cree pas de branches parce qu'il n'y en a pas besoin. C'est ce que je faisais sur mes premiers projets. Ca fonctionnait, dans le sens ou je ne perdais pas de code. Mais ce n'etait pas vraiment utiliser Git.
La rupture est venue en stage. Des mon arrivee chez Apiqa communication, j'ai vu une organisation completement differente. Chaque tache est liee a une issue. Chaque issue donne lieu a une branche dediee. Le code ne rejoint jamais main directement : il passe par une pull request, qui peut etre relue, commentee, et validee avant le merge.
Au debut, ce workflow m'a semble lourd. Pourquoi creer une branche pour une modification de deux lignes ? Pourquoi ouvrir une pull request quand on pourrait juste pousser ? La reponse est venue en observant ce que ce systeme permet : la tracabilite. A tout moment, on peut savoir qui a fait quoi, pourquoi, et dans quel contexte. Le code a une histoire lisible.
Les issues ont aussi change ma facon de planifier. Plutot que de coder dans tous les sens et de voir ce qui emerge, decomposer le travail en issues force a reflechir avant de commencer. Qu'est-ce que cette tache doit accomplir exactement ? Quelle est sa definition de done ? Ce sont des questions qu'on ne se pose pas quand on code seul sans methode.
Ce que j'ai appris, en resumant, c'est que Git n'est pas juste un outil de versioning. C'est un outil de communication dans une equipe. Les messages de commit, les noms de branches, les descriptions de pull requests : tout ca raconte une histoire a tes collegues, et a toi-meme dans six mois quand tu relis le code.
Aujourd'hui, meme sur mes projets personnels, j'essaie de maintenir ces habitudes. Pas parce que c'est obligatoire quand on est seul, mais parce que c'est un reflexe professionnel qui se construit dans la repetition. Et parce que la prochaine fois que je travaillerai en equipe, je n'aurai pas a tout reapprendre.