Travailler avec les versions : branches, fusions et historique
Un flux simple
Une branche principale stable, des branches courtes par changement, une fusion après revue et tests. Une branche qui vit deux semaines créera des conflits et une fusion effrayante — et c'est presque toujours le signe que la tâche est trop grande.
Messages de changement
Une première ligne courte disant ce qui a changé, puis pourquoi. Le « pourquoi » est ce qu'on ne peut pas récupérer du code, et ce qu'on cherchera dans un an.
Liez à la tâche ou à la discussion. Un changement sans contexte est une future énigme.
Hygiène
Ne stockez pas de fichiers construits, de secrets ou de gros fichiers dans le dépôt. Étiquetez les versions avec des tags. Et ne réécrivez pas l'historique déjà publié — cela casse le travail des autres.
Pour aller plus loin
Décidez d'une politique de fusion — conserver l'historique complet ou écraser en un seul changement — et appliquez-la. La cohérence compte plus que le choix lui-même, car un historique mixte est difficile à naviguer exactement quand on doit trouver quand quelque chose s'est cassé.