Blanche-Neige et les sept commits

Temps de lecture : 28 min

Un conte Git où les builds plantent, les branches se croisent, et le git blame révèle que la Reine, c’était ton lead tout ce temps.

Miroir, mon beau miroir

Il était une fois, dans un royaume lointain et dans un château nommé Repository, régnait une reine lead ingénieure. Cette Reine, aussi talentueuse que tyrannique, exigeait que tous les développeurs du royaume travaillent directement sur la branche principale du repository – une branche nommée main – sans broncher. Chaque jour, la Reine consultait son miroir magique, qui n’était autre qu’une pipeline CI/CD brillante accrochée au mur du château. Elle lui demandait : « Miroir, mon beau miroir, quel est le code le plus propre du royaume ? » Et le miroir analysait les builds et les tests pour répondre : « c’est vous, ô ma reine ».

Un beau matin, le miroir répondit avec une légère hésitation : « Ô ma Reine, ton code est élégant, mais un nouveau commit a surpassé la qualité du tien. Blanche-Neige, la jeune développeuse junior, vient de pousser un commit encore plus propre et bien testé ! » La Reine devint verte de rage. Blanche-Neige, douce et modeste, était une développeuse au cœur pur qui commitait soigneusement son code et écrivait des tests unitaires pour chaque fonctionnalité. Son dernier commit avait fait passer tous les tests de la pipeline au vert du premier coup, ce qui attira malgré elle la jalousie de la Reine.

Blanche-Neige ne se doutait de rien. Concentrée à son bureau, elle venait justement d’enregistrer un commit important sur le dépôt. Ce commit implémentait une nouvelle fonctionnalité demandée par le royaume : l’authentification sécurisée par le sourire d’un poney. Elle tapa la commande magique pour sauvegarder son travail.

Git commit : Un commit correspond à un instantané des changements dans le code, enregistré dans l’historique du projet avec un identifiant unique. Chaque commit contient les modifications apportées, l’auteur, la date et un message descriptif expliquant le changement . Les commits forment ainsi une suite chronologique d’instantanés, ce qui permet de suivre l’évolution du projet et de revenir à un état antérieur en cas de besoin. Exemple – Sauvegarder des changements avec un message : git commit -m "Ajoute la fonctionnalité d'authentification avec le sourire d'un poney"

Le commit de Blanche-Neige fut salué par le miroir magique : build réussi, 100% des tests passés, couverture de code exemplaire. C’était la preuve éclatante de la maîtrise de Blanche-Neige en matière de bonnes pratiques. Lorsque la Reine vit s’afficher ces résultats dans le miroir, elle comprit que le talent de la jeune développeuse menaçait sa suprématie. Déterminée à rester la plus compétente du royaume, la Reine forgea un plan maléfique pour se débarrasser de Blanche-Neige et de ses commits exemplaires.

La fuite sur la branche enchantée

Ce soir-là, la Reine convoqua un développeur mercenaire – le Chasseur de bugs, un ingénieur compétent – et lui donna un ordre funeste : « Trouve Blanche-Neige, et supprime-la du projet à jamais. Supprime son accès au dépôt, efface sa branche si elle en a une, et ramène-moi la preuve de sa disparition. » Le Chasseur, bien qu’il fût habitué à traquer des bugs tenaces dans le code, eut le cœur serré. Il connaissait Blanche-Neige et admirait secrètement son code clair et bien structuré.

Le lendemain, il emmena Blanche-Neige en « revue de code » dans la forêt du repository local, prétextant vouloir l’aider sur une tâche. Arrivés au plus profond du repository local (loin du château et de la vigilance de la Reine), il lui révéla discrètement la vérité : « Blanche-Neige, la Reine m’ordonne de te bannir du projet et de supprimer ton travail… Mais je ne peux m’y résoudre. Sauve-toi ! Crée une copie de ton travail en dehors du repository du château et pars loin, sur une branche où la Reine ne te trouvera pas. »

Blanche-Neige, effrayée, comprit qu’elle devait agir vite. Avant de s’enfuir, elle rassembla précieusement son code en cours. Elle avait des modifications non terminées dans son répertoire de travail qu’elle ne voulait pas perdre, mais elle n’avait pas le temps de les finaliser pour un commit. Le Chasseur lui souffla une astuce : « Utilise la commande secrète git stash pour cacher ton travail en cours comme on cacherait un trésor, tu pourras le récupérer plus tard ! » Sur les conseils du Chasseur, Blanche-Neige exécuta la commande magique qui sauvegarda ses changements en lieu sûr, puis nettoya l’arbre de travail.

Git stash : La commande git stash permet de mettre de côté temporairement les modifications en cours (suivies ou non suivies) dans le dépôt local. En d’autres termes, elle stashe les changements non commités pour pouvoir changer de contexte sans perdre son travail, puis les réappliquer plus tard . Cette fonctionnalité est très utile si l’on doit interrompre ce que l’on fait (par exemple, pour corriger un bug urgent sur une autre branche) sans avoir à créer un commit incomplet. Exemple – Sauvegarder les changements en cours : git stash (puis plus tard, restaurer avec git stash pop)

Une fois les changements mis en lieu sûr, Blanche-Neige suivit le Chasseur vers une bifurcation de chemins dans la forêt du code. Là, le Chasseur lui montra comment créer une nouvelle voie de développement, loin de la branche main du château. Blanche-Neige exécuta la commande pour créer une branche rien qu’à elle, un refuge où la Reine ne pourrait pas aisément la trouver. Elle appela cette branche feature/blanche-neige.

Git branch : Une branche représente une ligne de développement indépendante dans Git. Techniquement, une branche est un pointeur léger vers un commit spécifique, qui se déplace à chaque nouveau commit . Travailler sur une branche séparée permet d’isoler des changements – par exemple pour développer une nouvelle fonctionnalité ou corriger un bug – sans impacter la branche principale (main). Ainsi, le code instable n’est pas mêlé tout de suite au code en production, et on peut nettoyer l’historique de la branche avant de la fusionner dans main . Exemple – Créer et basculer sur une nouvelle branche feature : git checkout -b feature/blanche-neige

Blanche-Neige venait ainsi de brancher son destin, quittant la trajectoire imposée par la Reine. Le Chasseur, pour sauver les apparences, retourna au château avec un leurre : il supprima un faux compte utilisateur et montra à la Reine un vieux badge d’accès en prétendant que c’était celui de Blanche-Neige, banni du dépôt. La Reine, crédule et satisfaite, crut que Blanche-Neige ne commettrait plus jamais de code qui puisse la faire ombrage. Pendant ce temps, Blanche-Neige s’enfonçait dans la forêt du repository local sur sa nouvelle branche, seule mais libre de coder selon ses bonnes pratiques.

La maison des sept commits

Après une longue errance dans la forêt des fichiers et des répertoires, Blanche-Neige tomba sur une petite maison cachée derrière des arbres. Curieusement, la porte du repository était entrouverte. Fatiguée et affamée, elle entra prudemment et découvrit un chaos charmant : sept petits postes de travail, sept mugs de café froid, et du code en pagaille sur les écrans, comme si leurs utilisateurs étaient partis à la hâte.

Intriguée, Blanche-Neige inspecta le lieu. Elle se rendit compte que la maison était occupée par sept nains développeurs, connus dans le royaume comme les sept commits. Chacun d’eux était petit par la taille mais grand par son expertise dans un aspect de Git. Il y avait Prof (le sage architecte logiciel), Grincheux (le grognon qui râle quand le build échoue), Joyeux (toujours enthousiaste à tester de nouvelles librairies), Atchoum (qui casse souvent le code par mégarde mais le répare en éternuant des correctifs), Dormeur (spécialiste des délais et des pauses stash fréquentes), Timide (n’ose pas pousser son code sans revue) et Simplet (pas si simple, il adore expérimenter des commandes Git ésotériques).

Voyant le désordre du projet dans la maisonnette – tests en échec, fichiers non organisés – Blanche-Neige ne put s’empêcher de mettre un peu d’ordre. Elle lança quelques scripts pour réorganiser les fichiers, exécuta un git status pour lister l’état du dépôt, et même écrivit un petit README pour clarifier le but du projet des nains. Après avoir nettoyé le code comme elle l’aurait fait de la maison, elle s’endormit, épuisée, sur un banc devant la cheminée, entourée des crépitements du feu et de quelques lignes de code qui défilaient encore dans sa tête.

Le soir venu, les sept nains revinrent de leur data mining . En entrant, ils furent stupéfaits de trouver leur maison en ordre, leur code refactorisé par une main inconnue, et Blanche-Neige endormie.

D’abord méfiants, ils émirent des protestations. Mais Prof, le chef du groupe, s’approcha prudemment et reconnut Blanche-Neige. Tous avaient entendu parler de la développeuse injustement chassée du château. Joyeux s’écria : « La Blanche-Neige de la branch main ! Quelle joie de te voir ici vivante ! »

Grincheux grogna qu’elle avait touché à leur repo, mais même lui devait admettre que ses améliorations avaient corrigé plusieurs warnings du linter. Timide demanda doucement si elle allait bien.

Blanche-Neige se réveilla en sursaut au milieu de cette petite assemblée. Elle expliqua son histoire : la jalousie de la Reine, l’ordre d’exil, la fuite sur sa branche. Les nains, indignés, l’assurèrent qu’elle pouvait rester avec eux aussi longtemps qu’elle le souhaiterait. « Ici, tu es sur une branche isolée, à l’abri du main maléfique de la Reine, » plaisanta Atchoum avant d’éternuer. « Nous aussi, nous travaillons en dehors du château, chacun sur nos branches. Et on ne merge dans main qu’en dernière étape, après s’être relus entre nous. »

Blanche-Neige découvrit le quotidien des sept nains commits. Chaque nain avait sa spécialité Git et ils collaboraient harmonieusement, loin des yeux de la Reine, sur un projet open-source secret. Le soir, avant de se coucher, ils intégraient leurs travaux de la journée ensemble.

« Ici, on aime fusionner nos efforts, » dit Prof. « Chaque fois qu’une fonctionnalité est prête, on la intègre au projet commun en faisant un merge bien propre. » Blanche-Neige acquiesça, ravie de voir de bonnes pratiques collaboratives. Elle se souvint combien au château la Reine imposait des merges chaotiques directement sur main sans relecture. Chez les nains, c’était tout le contraire : on fusionnait méthodiquement, dans la bonne humeur.

Git merge : La fusion (merge) combine le travail de différentes branches en une seule. La commande git merge permet de prendre les lignes de développement indépendantes créées avec git branch et de les intégrer ensemble dans une branche cible . En pratique, Git crée alors un commit de merge qui a deux parents (un parent pour chaque branche fusionnée) et réunifie les historiques de commits. Si les mêmes zones du code ont été modifiées de façon incompatible sur chaque branche, Git signale un conflit de merge et demande une intervention manuelle pour décider quoi garder. Exemple – Fusionner la branche feature/blanche-neige dans la branche develop courante : git merge feature/blanche-neige

Blanche-Neige collabora rapidement aux tâches quotidiennes. Le matin, chacun des nains partait coder sur sa branche, et le soir ils se retrouvaient pour intégrer leurs commits. Cette organisation assurait une grande stabilité au projet commun. Blanche-Neige se mit à faire de même : elle travaillait sur sa branche personnelle, puis fusionnait ses commits avec ceux des nains une fois ses modifications prêtes et validées par ses camarades.

Leçons de Git chez les nains

Les jours passèrent, et Blanche-Neige apprit énormément aux côtés des sept nains. Chaque concept de Git prenait vie à travers leurs astuces et anecdotes.

Un jour, Prof montra à Blanche-Neige comment ils gardaient un historique propre avant d’envoyer le code vers le dépôt central. « Parfois, nous utilisons git rebase pour linéariser l’historique de nos commits, » expliqua-t-il. « Plutôt que d’avoir des embranchements partout, on rebase nos branches de fonctionnalité sur la dernière version de develop avant de fusionner, ainsi on a l’impression que tout a été développé d’un seul tenant. » Il l’avertit cependant de la prudence nécessaire : « On ne rebase jamais les commits qui ont déjà été poussés au dépôt distant du château. Ce serait réécrire l’histoire publique, et la magie noire de l’histoire réécrite peut semer le chaos. » Blanche-Neige hocha la tête, comprenant qu’un rebase mal avisé pouvait fâcher les esprits de l’intégration continue.

Git rebase : Le rebase (ou rebasage) permet de déplacer ou rejouer une suite de commits sur une autre base. Autrement dit, on prend les commits d’une branche et on les applique sur un autre commit (souvent la pointe de la branche principale), ce qui réécrit l’historique du projet . Après un rebase, la branche semble contenir des commits linéaires partant du nouveau point de base, comme si on l’avait développée à partir de la dernière version à jour. Cela permet d’avoir un historique plus linéaire et d’éviter des commits de merge inutiles, mais attention : il ne faut jamais rebaser une branche publique (déjà poussée à un dépôt distant), sous peine de provoquer des incohérences pour les autres collaborateurs . Exemple – Mettre la branche courante à jour en la basant sur main : git rebase origin/main

Blanche-Neige maîtrisa vite l’art du rebase et aida à refaire l’historique de la branche du projet des nains pour que les commits suivent une belle suite logique. Ensemble, ils amendèrent quelques commits (Prof lui montra même git commit --amend pour modifier le dernier commit, mais ceci est une autre histoire).

Un autre jour, Atchoum introduisit sans le vouloir un petit bug en refactorisant le module de notification par pigeon voyageur. Le soir venu, en testant le projet commun, les nains découvrirent le bug : l’application se mettait à éternuer une erreur fatale. Grincheux grommela : « Qui a cassé le build ?! Je parie que c’est Simplet qui a encore fait des siennes. » Simplet protesta vigoureusement de son innocence. La tension montait entre les nains, chacun suspectant l’autre d’être à l’origine du problème. Blanche-Neige, gardant son calme, intervint : « Mes amis, utilisons plutôt la commande git blame au lieu de vous chamailler. Elle nous dira exactement quel commit a introduit le bug et qui en est l’auteur. »

En deux temps trois mouvements, Blanche-Neige exécuta git blame sur le fichier incriminé. Chaque ligne fut annotée avec l’empreinte du dernier commit l’ayant modifiée, et le coupable apparut clairement : c’était un commit d’Atchoum (il avait involontairement supprimé une ligne en éternuant, apparemment). Immédiatement, ils se mirent tous au travail pour corriger le bug ensemble.

Git blame : La commande git blame permet d’annoter chaque ligne d’un fichier avec le dernier commit qui l’a modifiée ainsi que l’auteur de ce commit . C’est un outil précieux pour retracer l’origine d’un changement dans le code. Par exemple, si un bug apparaît sur une ligne, git blame indique quel commit (et quel développeur) a introduit cette ligne pour faciliter le debug ou discuter de cette partie du code avec l’auteur. Exemple – Identifier l’auteur des modifications d’un fichier : git blame chemin/vers/fichier.ext

Grâce à git blame, les nains purent localiser le bug précisément. Plutôt que d’accabler Atchoum, ils utilisèrent cette information pour résoudre rapidement le problème. Prof suggéra de revenir au commit précédent pour voir comment fonctionnait le code avant l’erreur. Timide proposa même d’utiliser git revert pour annuler le commit fautif d’Atchoum, puis de recommencer la modification plus proprement, ce qu’ils firent.

Git revert : La commande git revert sert à annuler un commit spécifique en créant un nouveau commit qui effectue l’inverse du commit ciblé . Contrairement à d’autres commandes d’annulation (comme git reset qui déplace la référence HEAD en arrière), git revert préserve l’historique : elle n’efface aucun commit existant mais ajoute un commit de « revert » qui introduit les modifications inverses. Ainsi, l’historique conserve la trace du commit annulé et de son annulation, ce qui est plus sûr dans un contexte collaboratif . Exemple – Créer un commit annulant le commit identifié par son SHA : git revert abc1234

En revertant le commit problématique, puis en appliquant une correction soigneuse, les nains et Blanche-Neige rétablirent la stabilité du projet. Le pipeline de tests repassa au vert, pour la plus grande satisfaction de Grincheux.

Blanche-Neige était émerveillée par toute la magie de Git qu’elle apprenait auprès des sept nains commits. Elle découvrit aussi la commande git cherry-pick grâce à Simplet : celui-ci lui montra comment, si une correction de bug avait été faite dans une branche mais qu’on en avait besoin tout de suite dans une autre (par exemple dans main), on pouvait « cueillir » le commit en question et l’appliquer ailleurs sans fusionner toute la branche. « C’est comme ne prendre qu’une cerise sur le gâteau, sans avaler le gâteau entier ! » expliqua Simplet.

Git Cherry-pick : La commande git cherry-pick est un outil puissant qui permet de choisir un commit spécifique (identifié par son SHA ou référence) et de l’appliquer sur la branche courante . En pratique, cela signifie que l’on peut intégrer un changement particulier depuis une autre branche, sans procéder à un merge complet de cette branche. Par exemple, si un commit de correction a été fait par erreur sur la branche X au lieu de main, il suffit de se placer sur main et de cherry-picker ce commit pour l’y intégrer . Cela duplique le commit sur la branche cible. Attention, l’usage abusif de cherry-pick peut conduire à dupliquer des commits et créer de la confusion ; il est à utiliser avec parcimonie lorsque la situation le justifie. Exemple – Appliquer le commit abc1234 (référence SHA) sur la branche courante : git cherry-pick abc1234

Blanche-Neige pratiqua le cherry-pick sous l’œil bienveillant de Simplet, comprenant l’intérêt de cette commande pour porter rapidement des correctifs critiques d’une branche à l’autre.

Entourée de cette communauté de développeurs solidaires, Blanche-Neige reprenait confiance en elle. Chaque commit qu’elle faisait était relu par Prof ou Joyeux, chaque merge était un moment de fête (avec le fameux message de merge « Merge pull request – et ils fusionnèrent heureusement » qu’ils aimaient écrire en clin d’œil), et même Grincheux finit par sourire en voyant à quel point Blanche-Neige codait proprement.

Pendant ce temps, au château du Repository Distant, la Reine se félicitait, pensant Blanche-Neige disparue à jamais. Le miroir, n’ayant plus de commits de Blanche-Neige à analyser, continuait de valider les builds de la Reine. Cependant, l’ombre de Blanche-Neige planait encore dans l’esprit de la Reine. Un commit fantôme apparut un jour dans le journal : en synchronisant le repo du château avec l’amont open-source, un des commits de Blanche-Neige (co-écrit avec les nains) se retrouva référencé. La Reine, surprise, interrogea fébrilement son miroir : « Miroir magique, explique-moi pourquoi je vois encore la patte de Blanche-Neige dans le code ?! » Le miroir afficha en réponse : « Blanche-Neige n’est pas morte pour le projet, elle contribue ailleurs… et ses contributions sont appréciées. » La Reine entra dans une colère noire en comprenant que Blanche-Neige était toujours en vie quelque part, et qu’en plus, elle continuait de coder et de briller hors de sa portée.

Le commit empoisonné

Déterminée à achever ce qu’elle avait commencé, la Reine élabora un plan plus retors. Elle décida de se déguiser en humble contributrice open-source, tel un vieux colporteur apportant un cadeau, afin de tromper Blanche-Neige et infiltrer son code. Elle créa un utilisateur GitHub sous le pseudonyme de @OldCoder, une vieille développeuse apparemment bienveillante, et prépara un commit empoisonné : une modification subtile du code, promettant d’optimiser les performances, mais qui en réalité introduisait une faille critique.

Un matin, alors que Blanche-Neige était seule, une gentille vieille dame frappa à la porte du dépôt local. « Bonjour ma chère, » dit la vieille, « je suis une contributrice de passage. J’ai entendu parler de ton merveilleux projet et j’aimerais vous offrir un petit snippet de code pour améliorer votre application. » Dans sa main ridée, elle tenait un fichier de code : la pomme empoisonnée était en réalité un patch contenant un commit soigneusement préparé.

Blanche-Neige, toujours généreuse et confiante, ne reconnut pas la Reine déguisée. Ravie de voir qu’une développeuse expérimentée s’intéressait à leur projet, elle la remercia et accepta de jeter un œil au patch. Le code semblait ingénieux, apportant effectivement une optimisation. La vieille contributrice l’encouragea : « Vas-y mon enfant, intègre-le donc. Un petit git merge de ma branche ne pourra que faire du bien à ton projet. » Blanche-Neige hésita un instant – après tout, les nains n’étaient pas là pour faire une revue de code. Mais la vieille dame insistait avec un sourire apparemment bienveillant.

Alors Blanche-Neige décida de faire confiance. Elle fusionna le commit de la vieille contributrice dans la branche develop locale sur laquelle elle travaillait. Le merge se passa étrangement : le code s’intégra, mais aussitôt, le miroir, que Blanche-Neige consultait via un service CI connecté à leur dépôt open-source, vira au rouge écarlate. Les tests échouèrent tous d’un coup ! Le build se mit à cracher des erreurs fatales, l’application ne se lançait plus. En quelques secondes, Blanche-Neige comprit qu’elle avait été trompée : le commit était empoisonné. Un conflit de merge interne terrifiant se produisit dans le code, mêlant des éléments incompatibles. Elle tenta de revert le commit empoisonné, mais il était trop tard : des fichiers critiques avaient été altérés de façon subtile. Sous le choc et la panique, Blanche-Neige perdit connaissance, comme si le crash de l’application l’avait frappée de plein fouet. Elle s’effondra, tout comme le serveur de l’application d’ailleurs, qui venait de planter.

Conflit de merge : Un conflit de merge survient lorsque Git ne parvient pas à fusionner automatiquement deux ensembles de modifications . C’est généralement le cas lorsque deux contributions concurrentes modifient la même portion du code de façons incompatibles (par exemple, deux développeurs éditent la même ligne différemment, ou l’un modifie un fichier que l’autre a supprimé). Git marque alors les sections conflictuelles dans les fichiers avec des délimiteurs (<<<<<< HEAD, =======, >>>>>> branch) pour signaler les deux versions en compétition. Tant que le conflit n’est pas résolu manuellement par le développeur (en choisissant quoi conserver ou en combinant les modifications) et que le merge n’est pas finalisé par un commit de merge, le projet reste dans un état intermédiaire . La bonne pratique pour limiter les conflits est de travailler sur des branches isolées et de synchroniser régulièrement les changements en amont. Exemple – En cas de conflit, on peut utiliser git status pour lister les fichiers en conflit, puis éditer ces fichiers pour y résoudre les marqueurs de conflit manuellement, avant de faire git add sur les versions corrigées et git commit pour terminer la fusion.

La Reine, satisfaite, dévoila son identité alors que Blanche-Neige gisait inconsciente devant son terminal. « Pauvre petite, » ricana-t-elle, « ce commit t’a été fatal. Plus jamais tu ne feras de l’ombre à mon code ! » Elle laissa Blanche-Neige ainsi, dans un sommeil profond causé par le build brisé, et repartit en hâte vers le château, certaine d’avoir gagné.

Peu après, les sept nains revinrent de leur journée de travail et trouvèrent Blanche-Neige effondrée sur le clavier, son écran affichant des erreurs rouges clignotantes. Horrifiés, ils comprirent qu’un commit malveillant avait été injecté. Joyeux examina le journal des commits et s’écria : « Regardez, un commit étrange vient d’être mergé ! » Prof analysa le code et blêmit : « C’est du code empoisonné, une faille de sécurité critique a été insérée intentionnellement. Qui a pu faire ça ? » Grincheux montra du doigt l’auteur du commit : @OldCoder. « Ce pseudo ne me dit rien qui vaille… On dirait l’œuvre de la Reine déguisée, » grogna-t-il.

Les nains portèrent Blanche-Neige jusqu’à un serveur de build improvisé dans la maison – un endroit frais et sûr, comme un lit de verre, où son code reposerait en attendant d’être réparé. Ils essayèrent toutes sortes de commandes Git pour annuler le commit empoisonné : revert, reset, etc. Mais la Reine, rusée, avait non seulement introduit une faille, mais aussi fait en sorte qu’en la retirant brutalement, le système ne compile plus. « C’est un vrai nœud gordien de dépendances, » dit Simplet affligé. « On dirait qu’il faut reconstruire une partie du module pour éliminer proprement le poison… »

Durant des jours, les sept nains commits tentèrent de soigner le dépôt et de réveiller Blanche-Neige (qui, désespérée et épuisée, restait plongée dans une sorte de coma du code). Mais malgré leur expertise combinée, la tâche était ardue : le commit empoisonné avait créé un enchevêtrement complexe. La maison autrefois pleine de rires retentissait maintenant de soupirs et de stack traces. Les builds continuaient d’échouer, symbolisant le mal qui rongeait le projet et la santé de Blanche-Neige.

Le revert du baiser et la morale

Heureusement, cette histoire ne s’arrête pas là. Un beau jour, passa près de la maison un Prince développeur venu d’un royaume voisin. Attiré par les messages d’erreur et les lamentations des nains, il entra et découvrit la scène tragique : Blanche-Neige inanimée devant son code, et les nains abattus essayant en vain de réparer le dépôt. Le Prince, qui se trouvait être un excellent code reviewer, examina calmement le problème.

Il identifia rapidement le commit malveillant dans l’historique. « Ce commit étranger a corrompu l’application, » dit-il. « Mais je pense savoir comment la sauver. » Avec l’autorisation des nains, il se mit au travail. Le Prince commença par isoler les changements du commit empoisonné et utilisa sa propre magie : une combinaison de git revert pour annuler certaines parties et de re-développement pour celles qui nécessitaient une solution de remplacement. Son approche méthodique finit par porter ses fruits. Il écrivait du code avec assurance, ses doigts dansant sur le clavier tel un baiser de véritable amour sur le dépôt mourant.

Finalement, le Prince poussa un commit de sauvetage sur la branche de Blanche-Neige et relança le build. Tous retinrent leur souffle… Le miroir, qui ne brillait plus depuis des jours, se ralluma. Un à un, les tests passèrent du rouge au vert. Le build se conclut par un succès. Le sortilège était levé ! Blanche-Neige ouvrit les yeux, comme réveillée d’un long cauchemar. Autour d’elle, les nains exultaient : le code était de nouveau propre et fonctionnel, et Blanche-Neige était saine et sauve, ressuscitée par le baiser du commit correctif du Prince.

La joie fut immense dans la maisonnée. Blanche-Neige remercia le Prince chaleureusement, les larmes aux yeux. Ce dernier lui proposa alors de revenir au château du Repository Distant avec lui pour présenter la vérité et reprendre la place qui lui revenait dans le projet royal. Accompagnée des sept nains, Blanche-Neige se rendit au château de la Reine.

En apprenant que Blanche-Neige était vivante, qu’elle avait corrigé le projet avec l’aide du Prince et des nains, et qu’en prime elle avait les preuves du commit empoisonné, la Reine entra dans une fureur incontrôlable. Elle tenta une dernière ruse en exécutant un terrible git push --force sur la branche main pour écraser les changements apportés par Blanche-Neige et le Prince. Mais c’en était trop : les nains et Blanche-Neige l’en empêchèrent de justesse en révoquant ses droits d’accès juste avant qu’elle ne force le push. Le miroir s’écria alors : « NON ! » et indiqua que la branche main était protégée contre les push forcés grâce aux règles de protection. La Reine, démasquée et vaincue, fut bannie du dépôt pour toujours. On raconte qu’elle partit errer dans de lointains clusters Kubernetes, où ses commandes git tyranniques ne trouveraient plus de dépôt à corrompre.

Dès lors, Blanche-Neige, les sept nains commits et le Prince collaborèrent pour fusionner toutes les bonnes contributions accumulées. Blanche-Neige utilisa sa branche de travail qu’elle entretenait depuis chez les nains et la fusionna finalement dans main du dépôt du château, après une pull request exemplaire et approuvée par tous. Ce merge final se déroula sans conflit (grâce aux rebasages réguliers qu’elle avait faits pour rester à jour, et à l’aide du Prince pour résoudre ce qui restait). Le miroir afficha fièrement un vert éclatant pour ce déploiement en production. Le projet du royaume retrouva sa gloire, avec une architecture robuste et une équipe unie aux commandes.

Et ils vécurent heureux, mergeant fréquemment et commitant beaucoup.

Morale de l’histoire

Ensemble, Blanche-Neige et les sept commits nous enseignent qu’un projet logiciel ne prospère que grâce au travail d’équipe et aux bonnes pratiques Git :