Chemin principal : Accueil > Git > Ma politique de branches avec Git

Autre chemin : (Aller directement au contenu de l'article)

Ma politique de branches avec Git

dimanche 2 juin 2019, par Maïeul
Suivre la vie du site RSS 2.0 Forum

En préparant mon intervention sur Git au Stage LaTeX de juin, je me suis dit qu’il pouvait être utile que je résume, succinctement, ma politiquement de branchement avec Git.

Elle n’a rien de très original, mais je la trouve pratique, et je me la suis plus ou moins construite avec le temps, notamment à cause de mon travail sur (r)(e)ledmac.

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 ».

Notes

[1Principalement pour corriger des ruptures de comptabilité apportées par les évolutions de LaTeX.

[22 parce que cela concerne reledmac, cf. plus haut.

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

À propos

Titulaire d’un doctorat en théologie et d’un doctorat en histoire, sous la direction conjointe de Frédéric Amsler et d’Élisabeth_Malamut, je commence à partir du 1er août 2017 un travail d’édition critique des Actes de Barnabé.

Dans le cadre de la rédaction de mon mémoire de master puis de ma thèse de doctorat, j’ai été emmené à utiliser LaTeX, et j’ai donc décider de partager mes techniques. En effet, au cours de mes premiers apprentissages, j’ai découvert que les ressources indiquant les outils pour l’utilisation de LaTeX en sciences humaines étaient rares. Ceci m’a conduit à maintenir ou créer plusieurs packages LaTeX et à donner plusieurs formations.

J’ai reçu en 2018 le prix DANTE e.V pour mon travail autour de LaTeX, en particulier autour de reledmac et reledpar.

Par ailleurs, je suis membre actif de la communauté SPIP, au sein de laquelle j’administre le site Spip-Contrib. Je propose sur ce site quelques notes sur SPIP, en général à destination de webmestre.

Il m’arrive également de faire un petit peu de Python, de temps en temps.

Enfin, je tiens un blog de réflexions politiques et religieuses.

Maïeul