Principe numéro 1 : la branche master doit être utilisable à tout moment

Contrairement à SVN où le trunk sert souvent de branche de développement, la facilité de créer des branches en git fait qu’il vaut mieux garder une branche master toujours prête à fonctionner.

C’est pourquoi je ne commite jamais directement dans master, sauf pour corriger des coquilles dans le manuel.

Principe numéro 2 : une branche par issue

Pour chaque issue (ticket) ouvert, je crée une branche homonyme issueXXX où XXX est le numéro de l’issue.

Le premier commit de la branche contient un exemple complet minimal, permettant de cerner le problème.

Le dernier commit contient l’effacement de cet exemple, ainsi que l’enregistrement des logs de changement dans le fichier .dtx. Son message habituel est changelog + fixe #XXX. Le fixe #XXX permet de fermer automatiquement l’issue lors de la fusion dans master.

Je demande à la personne ayant ouvert l’issue de tester à partir de ces branches.

Si la résolution d’un ticket dépend de la résolution d’un autre ticket, je fusionne d’une branche à l’autre.

Si une personne rouvre une issue fermée, deux solutions :

• soit je considère qu’il s’agit en fait d’un problème différent, et dans ce cas je demande de rouvrir une nouvelle issue ;
• soit j’avais mal résolu le problème, et dans ce cas je crée une branche issueXXX-bis.

Principe numéro 3 : jamais de rebasage ou de fast-forward, toujours de la fusion de branche

Le principe de créer des branches est de pouvoir faire des développements parallèles. Il importe que la trace de ces développements parallèles soit conservée même une fois finis les développements. C’est pourquoi je ne rebase jamais les branches une fois un développement achevé, et je refuse les fast-forward.

Ainsi qu’expliqué ailleurs, le rebasage ne devrait être conservé que pour gérer le cas où mon dépôt distant et mon dépôt local n’ont plus le même historique. Comme je travaille quasiment seul, cela m’arrive rarement.

J’ai donc dans mon .gitconfig global les lignes suivantes :

 
[pull]
	ff = only
	rebase = preserve
[merge]
 	ff = false
 

Principe numéro 4 : une branche par release

Avant de sortir (« releaser ») une nouvelle version, je crée une branche. Le nom de cette branche correspond au numéro de version de la future release. Dans le cas de reledmac, comme en plus reledpar n’a pas le même numéro de version, j’utilise un tiret pour séparer les deux numéros. Cela donne donc x1.y1.z1-x2-y2-z2.

Dans cette branche :

• je fusionne les branches fonctionnelles / de débogage ;
• je corrige le cas échéant le changelog, pour adapter à la date effective de sortie ;
• je procède aux tests automatiques.

Puis je fusionne avec master, d’où je prépare la sortie effective.

Principe numéro 5 : une branche par version majeure

Avant reledmac, ils y avaient eledmac et ledmac. Dans mon système de codification, reledmac est la version 2, eledmac la version 1 et ledmac la version 0. J’ai donc une branche 1 et une branche 0 pour les rares cas où j’accepte d’intervenir sur ces anciennes versions [1].

Principe numéro 6 : une branche pour la relecture de l’anglais

Comme je demande régulièrement à des personnes de relire l’anglais et le manuel de reledmac/reledpar, j’ai créé une branche english2 [2]. Cette branche contient l’état des fichiers après la dernière relecture par un·e correcteur·trice. Je m’en sers pour proposer de ne relire que les nouvelles modifications en comparant english2 et master.

Principe numéro 7 : ne pas conserver les branches fusionnées

Une fois une branche fusionnée, je la supprime en local comme en distant.

Appendice : principe de numérotation des tags et des release

J’utilise un système simple de numérotation sur le mode x.y.z

• Un changement de x indique une rupture majeure, impliquant de grands changements. Dans le monde LaTeX, je change également le nom, pour faciliter la compatibilité ascendante des documents.
• Un changement de y indique de nouvelles fonctionnalités.
• Un changement de z indique une correction de bug.
• Parfois j’ajoute une lettre (a, b, c, etc.) pour indiquer une simple correction dans le manuel.

Mes tags correspondent simplement au numéro de version (pas de v. devant). Dans le cas de reledmac-reledpar, comme les deux paquets sont liés sur le dépôt et en distribution, mais sont néanmoins distincts, mes tags ont la forme macx1.y1.z1-parx2.y2.z2.

J’ai enfin des tags sur tests abandonnés, que je garde plus pour me dire « si jamais il me revient à l’idée de reprendre ce projet ».