J’ai travaille dans des equipes qui traitaient Git comme un rituel sacre et dans d’autres qui le traitaient comme un tiroir fourre-tout. Aucun de ces extremes ne livre du bon logiciel. Apres des annees a nettoyer des historiques chaotiques et a demeler des catastrophes de fusion, j’ai adopte une serie d’habitudes qui gardent les choses calmes. Aucune n’est ingenieuse. C’est justement le but.
Choisissez un modele de branches et cessez d’en debattre
Le modele compte moins que l’accord. Pour la plupart des equipes produit, j’utilise le developpement sur tronc commun avec des branches de fonctionnalite a courte duree de vie. Vous partez de main, vous travaillez un jour ou deux, vous fusionnez, vous supprimez la branche. Plus une branche vit longtemps, plus elle derive, et plus la fusion finale devient penible. Les branches de version a longue duree ont leur place dans un logiciel qui sort a cadence fixe vers des clients qui ne peuvent pas se mettre a jour a la demande, mais pour une application web deployee plusieurs fois par jour, elles ne sont que du poids inutile.
Ce que j’evite activement, c’est le montage GitFlow elabore ou develop, release, hotfix et feature s’entrelacent. J’ai vu ce systeme derouter les nouveaux pendant des semaines. Si votre deploiement est continu, vos branches devraient l’etre aussi.
Ecrivez des commits qui expliquent le pourquoi
Un message de commit est une note pour celui qui lira l’historique a 2h du matin pendant un incident, et cette personne pourrait etre vous. Le diff montre deja ce qui a change. Le message doit capturer pourquoi. Je garde la ligne de sujet sous environ cinquante caracteres, a l’imperatif, et j’utilise le corps pour expliquer le raisonnement quand le changement n’est pas evident.
fix: empeche le double paiement lors d'une nouvelle tentative
Le client de paiement reessayait sur un 504 alors que
le debit etait deja passe cote passerelle. On clef
desormais la requete avec un jeton d'idempotence pour
que la passerelle deduplique. Ferme #482.Les commits atomiques sont l’autre moitie de l’affaire. Un changement logique par commit. Quand un commit fait trois choses sans rapport, vous ne pouvez jamais en annuler une seule proprement, et le bisect devient inutile. Si vous ecrivez « et » dans une ligne de sujet, ce sont deux commits.
Rebasez votre propre travail, fusionnez le travail partage
C’est la regle qui evite le plus de douleur. Avant d’ouvrir une pull request, je rebase ma branche sur la derniere version de main pour que mes changements reposent sur la realite actuelle et que la relecture soit fluide. Mais des qu’une branche est partagee ou qu’une PR est ouverte et que d’autres l’ont regardee, j’arrete de rebaser et je fusionne, car reecrire un historique publie oblige tous les autres a recuperer leur etat local.
- Rebasez pour ranger vos commits locaux avant qu’ils soient publics.
- Utilisez le rebase interactif pour ecraser les inevitables commits « correction de faute » et « vraie correction ».
- Ne forcez jamais le push d’une branche sur laquelle d’autres construisent.
- Protegez main pour que personne ne puisse y pousser directement.
Gardez main toujours livrable
La propriete la plus precieuse d’un depot, c’est que main fonctionne toujours. Si main est au vert, vous pouvez sortir une version a tout moment, et un deploiement casse se repare en annulant une seule fusion. J’impose cela avec des verifications obligatoires : les tests et le linting doivent passer avant meme que le bouton de fusion apparaisse. Cela rejoint directement ma facon de mener les relectures, que j’ai abordee dans les bonnes pratiques de revue de code. Un historique propre rend les relectures plus rapides, et de bonnes relectures gardent l’historique propre. Les deux se nourrissent mutuellement.
Rendez l’annulation banale
Quand quelque chose casse en production, l’action sure la plus rapide est en general d’annuler, pas de deboguer en direct. Ecraser chaque PR en un seul commit sur main rend cela trivial : une PR est un commit, et l’annuler retire toute la fonctionnalite proprement. J’aime les fusions ecrasees pour cette raison precise sur le code applicatif, meme si pour les bibliotheques ou l’historique de chaque commit a une vraie valeur, je conserve l’historique complet.
Etiquetez vos versions pour toujours pouvoir repondre a « qu’est-ce qui tournait mardi dernier ». Une etiquette legere ne coute rien et transforme une question vague en reponse d’une ligne.
Quelques habitudes qui paient discretement
- Validez un .gitignore sense des le premier jour pour que secrets et artefacts de build n’entrent jamais dans l’historique. Retirer un identifiant fuite de l’historique gache un apres-midi.
- Tirez avec rebase par defaut pour eviter le bruit des commits de fusion a chaque synchro.
- Gardez des PR petites. Une PR de 200 lignes recoit une vraie relecture. Une PR de 2000 lignes recoit un tampon.
Git recompense la discipline plus que le savoir. Vous n’avez pas besoin de memoriser les commandes de plomberie. Vous avez besoin d’un petit ensemble d’accords que tout le monde suit vraiment. Le meme raisonnement revient quand je concois des stockages de donnees, ce que j’ai couvert dans les bonnes pratiques de schema de base de donnees, ou quelques conventions fermes tot epargnent un nettoyage enorme plus tard.