Une solution pour garder un bel historique GIT
Préambule
Par ici, nous allons parler de GIT.
Je voudrais rappeler qu’il n’y a pas une seule solution universelle.
Celle présenté ici ne peut donc pas coller exactement à vos besoins.
Mais elle pourra très certainement être une base ou bien des éléments à piocher pour construire la solution adapté à votre contexte 🙂.
La vision
Si nous considérons que le meilleur vient de ceux qui pratiquent, nous devons donc écouter la communauté des développeurs en capitalisant sur les expériences passées.
Cependant, il ne s’agit pas de suivre aveuglément tout ce qui est écrit mais bien de chercher ce qui est bon pour nous et ce qui pourrait fonctionner au sein de l’équipe dans laquelle nous travaillons !
Gérer des branches principales (à longue durée de vie)
La fameuse branche main, aujourd’hui, qui était plus connu sous le doux nom de master hier. Avec la dev, indéboulonnable et rassurante.
L’idée étant bien d’avoir le besoin et des comportements différents pour chacune de ces deux branches.
Sinon, autant se simplifier la vie dès le début, quitte à revenir sur ce fait et s’ajouter une autre branche principale.
En effet, plus de branches principales il y a, plus il y a de risque de conflits et/ou d’oublie de faire les mises à jours.
Très souvent, c’est sur ce type de branche que nous allons trouvé nos pipelines de CI/CD.
… et des branches secondaires (à plus courtes durées de vies)
Très souvent, ce type de branche est lié à une nouvelle fonctionnalité, un bug à corriger, un refacto à réaliser, une documentation à mettre à jour, etc…
Une branche est aussi souvent induit par une User Story ou un Product Backlog Item (ou une tâche enfant de ces derniers), dépendant du type de framework utilisé pour gérer vos projets.
Ce type de branche doit durer le moins de temps possible pour éviter les conflits potentiels avec des changements qui auront déjà été poussés sur les branches principales.
Qui sont dev ou main, dans notre exemple ci-dessus.
Nos modifications seront ensuite mergés/fusionnées, via une PR/MR.
Que choisir entre squash/rebase/merge lors de la validation des PRs/MRs ?
Lors de la validation, privilégier un rebase peut permettre de réduire les conflits à long terme plutôt que de faire des squash ou des merge.
En effet, l’historique de la branche de destination sera préservé.
Un squash reste utile, notamment lorsqu’un développeur travaille avec pleins de petits commits. S’il travaille en TDD, il pourrait être pertinent de faire un squash afin de fusionner tous ses commits en un seul, afin d’améliorer la lisibilité la branche principale.
Enfin, un merge commit, permets de créer un nouveau commit qui va reprendre tous les autre commits. Niveau lisibilité, nous verrons que ce commit provient d’une branche de travail passé.
Utiliser des prefix dans les descriptions
En utilisant la convention https://www.conventionalcommits.org/fr/v1.0.0/ ou une mise en œuvre de ces règles qui correspondra au mieux au contexte du projet sur lequel nous travaillons.
Ainsi, en imaginant que j’ajoute une nouvelle fonctionnalité, je pousserai un nouveau commit avec le message comme celui-ci :
1
2
3
feat: the name of a new file must be less that 50 char
to follow the XY principle
Il est ainsi conseillé de limiter la taille du message principale à 50 caractères et d’ajouter plus d’information si besoin dans la ligne en-dessous.
Par exemple, lorsque je résous des bugs ou que je fais des refactos, il m’arrive souvent d’intégrer des sources d’articles, de RFC, de documentation d’API pour aider à la justification de ce commit.
Faut-il faire des petits commits ou des grands commits ?
Un grand commit implique d’avoir des dizaines voir des centaines de modifications. Ce qui peut avoir du sens en fin de travaux, lorsque notre travail est prêt à passer en PR/MR.
La règle est qu’il n’y a pas de règle ! La chose la plus importante est que vous devriez vous engager régulièrement à commits le plus régulièrement possible. Cela va notamment permettre de tester des comportements et de voir rapidement si des tests plantent (en admettant qu’il y a des tests qui couvrent le code mis à jour …).
Conclusion
J’ai beaucoup parlé de Pull requests/Merge requests car c’est un type de fonctionnement que l’on trouve assez régulièrement dans les projets aujourd’hui.
Bien entendu, il est possible de ne pas travailler de cette manière, de faire du pair programming ou du mob programing et de pousser les modifications directement sur les branches principales.
Dans des très petites équipes ou des équipes très expérimentés et selon le contexte, cela sera sans doute adapté, tant que cela fonctionne.
De ma humble expérience, que cela soit en pair programming__ ou _mob programing, il est tout de même toujours utile de passer par une PR/MR. Cela permet de peut-être vérifier des éléments de CI particulier ou tout simplement de rejeter un coup d’oeil plus frais le lendemain, à froid !
Quelques sources
- https://www.dynamic-mess.com/developpement/git-merge-fast-forward-rebase-culture-git/
- https://meritis.fr/git-rebase-vs-git-merge-quelles-differences/
Je vous ai déjà parlé de ma règle universelle favorite, inspiré des scouts ? Sûrement pas assez 🙂.
Essayez de laisser ce monde un peu meilleur qu’il ne l’était quand y êtes venus. (Baden-Powell)