Extrait de l'émission CPU release Ex0087 : Gestion de versions de source.
Bonjour à toi, Enfant du Futur Immédiat, toi qui ne sait plus pourquoi tu as raturé ce sgouigouigoui la semaine dernière sur ton devoir de dessin.
Le principe du travail en équipe est immuable : c'est toujours la faute d'un autre. C'lui qui a cassé toute la prod, c'est surement Donald, Angela ou Emmanuel. Seulement on se retrouve vite dans une situation de délation, et un licenciement pour faute grave sans preuve peut vite conduire aux prud'hommes. La gestion de version de code source en a apporté une solution socialement acceptable.
Mais je vais un peu trop vite ! Il faut d'abord que je t'explique ce qu'est que la gestion de version de code source... ou plutôt comment faisait-on avant.
D'habitude, quand on enregistre un fichier texte, donc un code source, on écrase toujours l'ancienne version. Alors quand on a un gros projet, on faisait régulièrement des copies du répertoire de travail avec la date de copie. Et parfois dedans, des fichiers étaient des copies précédentes d'autres fichiers avec en extension .backup, .fonctionnel, .corrigé, .backup2… Si on voulait retrouver le moment où une fonction n'a plus marché, et donc le code source qui était encore fonctionnel, c'était la misère.
Autre problème, quand on était plusieurs à modifier des fichiers sur un même serveur, on se marchait souvent sur les pieds, ta sauvegarde écrasant la modification du collègue à l'étage en dessous.
Bref, c'était l'horreur
Et puis sont arrivés les premiers logiciels pour gérer les versions de code source. C'était dans les années 1970s et surtout en informatique industrielle. On commença à les voir disponibles pour PC à la fin des années 1990s.
C'était une révolution, mais elle demandait des contraintes pour la cause !
Au lieu de sauvegarder directement sa modification d'un coup assuré de touche F2, on devait prendre le temps d'écrire la raison des modifications. Et aussi de travailler avec un serveur central, un dépôt du code source, qui arbitre les fichiers du projets et comment chacun peut travailler dessus.
Tu tires depuis le dépôt, t'édites ta modification, tu commites la raison de ta modification, et tu pousses vers le dépôt.
Mais pas mal de gens se braquaient devant la nouveauté, maugréant contre la divinité du micromanagement
adulée par la Direction, alors que le système de version était poussée par quelques développeurs au même niveau que les râleurs pour d'autres raisons.
Le premier effet fut de détecter les conflits quand plusieurs personnes éditaient en même temps le même fichier. Il faut alors décider quelle modification était à garder. Une fois que les conflits furent arbitrés et donc résolus, on pouvait commencer à réfléchir différemment sur les projets conséquents : Plutôt que de travailler dans un seul espace temps, on imaginait de bifurquer dans le continuum et à causer d'arborescence et de branches. Donc une branche correspond à une évolution espérée… C'est à dire qu'on pouvait bifurquer le projet, et espérer plus tard refusionner deux branches vers la branche principale, celle qui donne le produit fini.
C'était la théorie.
J'ai vu des projets qui avaient plus de 20 branches, sur lequel on picorait des commits, on répliquait des modifications à gauche à droite, qu'on appliquait anarchiquement. Une horreur.
La bonne manière d'utiliser les versions veut qu'on réfléchisse en terme de branche de production, en branche de préproduction, en tickets, en branche d'évolution, en demande de fusion, en comité de revue, en termes de livraison acceptable, bref, ce que l'on appelle un processus… Mais maintenant, on sait pourquoi telle modification a eu lieue, avec les fameuses 5 questions en W
que se pose tout enquêteur rigoureux :
What
: quoi qu'a été modifié ;Where
: où que la modif a été faite ;Who
: qui l'a faite ;When
: quand l'a-t-il enregistré ;Why
: pourquoi.
Merci les gestions de versions, merci git le plus utilisé d'entre eux !
Enfant du Futur Immédiat, je te disais au début que La gestion de version a apporté la solution
; Eh ben oui : la commande git blame (git dénonce
) te dira qu'elle est l'andouille qui a rajouté ce bug dans la ligne 792 qui sévit depuis 4 mois.
Comme ça, tu peux aller le voir, lui mettre un soufflon, retourner à ta place, le dénoncer à ta hiérarchie, et revenir à ton projet.
Comment ça, brutal
?
Ah oui, j'oubliais, dans la poésie légendaire de son créateur Linus Torvalds, git
est à l'origine une insulte. Et je vous em🜟☭⁂‱
[La suite de cette chronique est une adaptation d'un billet antérieur de l'auteur]
Auteur : DaScritch
Illustration : GIT Branch and tag model for Master, HotFixes & Releases, CC MiguelPDL