Les branches - Gestion du code source

Imaginez un monde où l’apprentissage de la conduite automobile se ferait uniquement en circuit clos. L’automobiliste aurait appris à tourner le volant, accélérer, freiner, et, techniquement, maîtriserait parfaitement son véhicule. Muni de son permis de conduire, le novice découvrirait ensuite le monde réel, et de nombreuses règles pas toujours écrites. Faut-il conduire au milieu de la route ? Plutôt à droite ? Plutôt à gauche ? Et pourquoi y a-t-il partout des lumières vertes et rouges ?

C’est simple, lui expliquerait un conducteur moins novice, tu dois rouler à droite et t’arrêter au feu rouge.

Pas si simple, répondrait un conducteur plus expérimenté, car en Angleterre on roule à gauche et aux Etats-Unis on peut franchir le feu rouge (lorsqu’on tourne à droite).

Il en va ainsi de la gestion de code source, outil désormais omniprésent dans le monde des développeurs. Si chacun est capable de prendre un main les CVS, SVN, Git, Mercurial, etc, et est en mesure de faire un « commit » sur une « branche » , on constate qu’il n’y a pas de consensus sur les pratiques, qui de toute façon évoluent. Quelle quantité de code modifier avant de faire un commit ? Quand et pourquoi créer une branche ? C’est parce qu’il existe dans le monde plusieurs façon de faire que je souhaite partager mon expérience (sans aucunement prétendre d’avoir trouvé la méthode ultime)

1) Tous sur le trunk ! (et une branche par release pour les correctifs)*

Outil : SVN
Tous les développeurs travaillent sur le trunk (et y committent leurs modifications). Lorsque toutes les fonctionnalités prévues pour une release sont développées, on crée une release (d’où changement de numéro de version). Si des corrections sont à effectuer, on crée une branche (à partir du commit de release du trunk), nommée en fonction du numéro de release (par exemple 5.2). Les bugs sont corrigés à la fois sur la branche et sur le trunk (contrairement aux nouveaux développements , qui sont commités uniquement sur le trunk), et le paquet final est créé à partir de la branche avec u numéro de version mineure (par exemple 5.2.1)

2) Une branche par feature, que l’on assemble pour la release

Outil : Git
Une branche master contient le code de référence. Lorsqu’on commence à développer une nouvelle fonctionnalité, on tire une branche à partir de master (que l’on nomme selon la fonctionnalité) et on y commite les modifications. Lorsque qu’une release se prépare, on merge entre elles les branches des diverses fonctionnalités à livrer (on nomme cette nouvelle branche en fonction de la date de la release), c’est à partir de cette branche qu’on crée une release (on y corrige les éventuels bugs trouvés lors des derniers tests ou lors de la mise en production). Après la release, on reporte les modifications (à l’aide d’un merge) de la branche de release vers la branche master. Dans les branches des fonctionnalités en cours de développement, qui sont basées sur une version désormais obsolète de master, on utilise la fonctionnalité « rebase », qui récrit l’historique de la branche de telle manière à ce qu’elle reparte de la dernière version de master.

Notez les différences avec ce qui est habituellement recommandé comme bonnes pratiques.

  • La méthode 1 n’utilise pas la notion de merge de branche, fonctionnalité pourtant disponible dans SVN.
  • La méthode 2 diffère du processus « standard » de Git (https://nvie.com/posts/a-successful-git-branching-model/), qui préconise que lorsque le développement d’une fonctionnalité est terminé, sa branche doit être mergée dans la branche commune, qui sert de base pour les branches de release.

    Et pourtant, ces façons de travailler sont aussi pérennes !

    Alexis Beuraud, le 25 avril 2019