Git n’est pas préparé au tsunami du codage de l’IA

Le mois dernier, Mitchell Hashimoto, co-fondateur de HashiCorp, a déclaré publiquement qu’il déplaçait son populaire projet d’émulateur de terminal open source Ghostty de GitHub. GitHub gère le plus grand service au monde basé sur le système de contrôle de version distribué Git, créé par Linus Torvalds.

Autrefois utilisateur enthousiaste, Hashimoto a été déçu par les interruptions de service et les demandes d’extraction de plus en plus lentes. « Ce n’est plus un endroit pour un travail sérieux si cela vous bloque simplement pendant des heures par jour, tous les jours », a-t-il écrit.

Hashimoto n’a pas tardé à défendre Git lui-même : « Le problème n’est pas Git, c’est l’infrastructure sur laquelle nous comptons autour de lui : problèmes, relations publiques, actions, etc. »

Beaucoup ont imputé les performances de GitHub à Microsoft, qui a acquis la société en 2018. Mais pour être honnête, GitHub lui-même a connu un trafic plus important que prévu grâce à une prolifération de demandes d’extraction générées par l’IA.

En 2025, GitHub a enregistré une croissance de 206 % d’une année sur l’autre des projets générés par l’IA, mesurée par l’utilisation de scripts shell Bash, un moyen répandu d’exécuter des agents. Et plus de code IA signifie plus de bugs. Une étude de GitClear a révélé que le code généré par l’IA générait 10,83 problèmes par demande d’extraction, contre 6,45 pour la variété humaine à l’ancienne.

Notre nouvelle main-d’œuvre agentique soulève de grandes questions sur la manière dont l’ensemble du cycle de vie du développement logiciel (SDLC) devrait évoluer et sur l’opportunité de Git.

« Les agents nous poussent vers un flux continu », a prévenu Peco Karayanev, co-fondateur du fournisseur de plateforme DevOps Auptic, qui relie les déploiements basés sur Git avec des outils d’observabilité pour la remédiation basée sur les agents.

L’ensemble de la base d’utilisateurs d’Aumptic fonctionne sur une forme de Git, soit homebrew, soit auprès d’un fournisseur de services comme GitLab.

Compte tenu du volume et de l’ampleur des changements dans les dépôts, « nous avons besoin que Git commence à fonctionner de manière plus continue », a écrit Karayanev dans une interview par courrier électronique.

Les opérations Git, en particulier lorsqu’elles sont utilisées dans des déploiements automatisés de type GitOps, doivent toujours être gérées par des personnes. Les mises à jour, les validations, les poussées et les fusions sont souvent intégrés dans des séquences d’épisodes « stop/go » où quelqu’un doit appuyer plusieurs fois sur Entrée sur le clavier pour continuer le flux de travail, a noté Karayanev. Ce modèle pourrait ne plus tenir le coup une fois que les agents commenceront à avoir la priorité.

Un majordome pour Git

Git a toujours eu son lot de critiques, notamment celles qui utilisent l’outil au quotidien.

Il n’existe peut-être pas d’autre logiciel aussi largement adopté et pourtant aussi impénétrable. Torvalds et d’autres développeurs du noyau Linux ont construit Git en 2005 après avoir été frustrés d’essayer d’intégrer du code Linux dans l’outil commercial BitKeeper. Linux, un projet de groupe mondial aux proportions gigantesques, nécessitait un système de contrôle de version distribué capable de prendre en charge le développement non linéaire de milliers de branches parallèles.

Comme tout système distribué, Git peut être difficile à comprendre.

L’un des co-fondateurs de GitHub, Scott Chacon a co-écrit un livre sur l’utilisation de Git (Pro Git de 2009) et se retrouve parfois déconcerté par le système de contrôle de version.

Il y a encore des « bords tranchants » dans Git, a déclaré Chacon Til s’inscrit. « Il y a beaucoup de choses pour lesquelles il ne fonctionne pas très bien du point de vue de la convivialité », a-t-il déclaré.

Chacon a cofondé GitButler dans le but de « repenser la porcelaine » de Git, afin de rendre Git plus adapté aux flux de travail modernes. (Le mois dernier, GitButler a reçu 17 millions de dollars en capital-risque).

Considérez GitButler comme un client Git surpuissant. Il permet au développeur de travailler simultanément sur deux branches différentes, en utilisant une technique appelée branchement virtuel. Il réconcilie le code sur lequel un développeur travaille avec le code en amont. Ils peuvent réorganiser les commits ou modifier les commentaires d’un commit précédent. Il offre des métadonnées plus riches sur les fichiers sur lesquels vous travaillez. Il peut montrer quels commits sont uniques à cette branche.

Mieux encore, il élimine ce que de nombreux développeurs appellent « l’enfer du rebase », où les fusions dans une base de code mise à jour doivent être vérifiées une par une, un problème que GitButler résout en gardant le code de l’utilisateur synchronisé avec ce qui est en amont.

Beaucoup de ces actions proposées par GitButler peuvent être effectuées via la commande Git elle-même – bien que le langage de commande de Git et ses règles puissent être si obtus que « vous ferez probablement une erreur à un moment donné », a déclaré Chacon.

Un Git pour les agents

Chacon pense que les problèmes de fiabilité actuels de GitHub proviennent du tsunami actuel du travail agent.

C’est « ironique » car GitHub a été conçu pour faire évoluer Git, a-t-il déclaré. « Mais l’afflux d’agents pousse le service au bord du gouffre. »

Le problème ne vient pas de Git lui-même, mais du fait que tout le monde utilise un seul service, a soutenu Chacon. L’année dernière, GitHub comptait environ 180 millions d’utilisateurs travaillant sur 630 millions de référentiels, dont 121 millions créés rien qu’en 2025, selon le dernier rapport annuel Octoverse de la société.

« Dans une perspective à long terme, il n’est pas nécessaire que cela se passe ainsi », a-t-il soutenu. Peut-être que Git devrait être exécuté localement, mis en miroir globalement et géré avec des clients… comme GitButler, a suggéré Chacon. Peut-être que les systèmes de contrôle de version basés sur Git pourraient être personnalisés pour des secteurs industriels spécifiques.

Nous devons réfléchir à la façon dont nous « distribuons davantage ces systèmes », a-t-il déclaré. « Git est conçu pour être distribué mais nous ne le distribuons pas », a-t-il déclaré.

GitButler a créé une interface de ligne de commande spécifiquement pour les agents. Il a été conçu pour donner aux serveurs MCP une carte intégrée du référentiel, ce qui nécessiterait autrement de regrouper plusieurs commandes Git. Le concept de fichiers virtuels permet à l’agent de travailler sur une section de code sur laquelle travaille également un développeur ou un autre agent.

Ce sont des changements qui indiquent qu’il faut repenser la façon dont un workflow Git doit s’exécuter.

« Je pense que tous ces systèmes devraient fondamentalement changer, car tous nos flux de travail ont changé, n’est-ce pas ? Il doit y avoir des sortes de primitives différentes pour savoir comment gérer ces ensembles de problèmes », a déclaré Chacon.

Un conseil du développement de jeux

Une entreprise qui souhaite que sa plate-forme remplace complètement Git est Diversion, qui a construit un système de contrôle de version distribué éponyme initialement destiné à la conception de jeux à grande échelle.

« L’architecture de Git est en fait un problème qui empêche la mise à l’échelle », affirme Sasha Medvedovsky, PDG de Diversion, dans une interview avec Le registre. « Fondamentalement, il s’agit d’un problème d’architecture qui ne peut pas être résolu et qui constitue un goulot d’étranglement pour les utilisateurs finaux et les services d’hébergement. »

Git est un système distribué dans la mesure où chaque utilisateur, ou service hébergé, nécessite une base de données dédiée (un peu comme la blockchain). « Il n’est pas distribué au sens habituel du terme mais plutôt reproduit », a-t-il écrit dans un échange avec The Register sur LinkedIn.

Les opérations s’exécutent sur un seul thread, ce qui rend les opérations simultanées impossibles. En conséquence, plus le référentiel est grand, plus les opérations de validation sont lentes – une combinaison mortelle pour le développement rapide de logiciels agentiques, a noté Medvedovsky.

Bien sûr, chaque PDG aura préparé ses arguments sur les faiblesses d’un concurrent (Diversion est en train de finaliser un article de blog avec des chiffres concrets sur les performances de Git et GitHub). Mais il existe un nombre croissant d’autres initiatives visant à préparer Git aux temps difficiles à venir.

Le plus remarquable est peut-être Jujutsu, un système de contrôle de version distribué compatible Git, géré par l’ingénieur logiciel principal de Google, Martin von Zweigbergk. Comme GitButler, Jujutsu (jj) vise à éliminer de nombreux désagréments liés à Git. Il comprend un bouton d’annulation et la possibilité de continuer à valider même en cas de conflit.

Et parce que tout ce qui est écrit en C doit être refondu dans Rust de nos jours, Sebastian Thiel, contributeur de longue date de Git, a lancé un projet appelé Gitoxyde pour reconstruire Git dans Rust. Les avantages potentiels incluent des améliorations significatives des performances grâce au traitement multicœur et la sécurité de la mémoire indispensable fournie avec Rust.

Git 3 résoudra-t-il tous les problèmes ?

Le responsable de la maintenance de Git est Junio ​​Hamano, qui a pris les rênes de Torvalds en 2005. Et il reste occupé à maintenir Git à jour.

Au FOSDEM en février dernier, Patrick Steinhardt, contributeur principal de Git et responsable de l’ingénierie de GitLab, a discuté de certains des changements à venir dans la prochaine version de Git, la version 3, qui est progressivement déployée cette année.

L’une des principales améliorations résidera dans la manière dont Git gère les références de validation, les identifiants qui pointent vers chaque modification effectuée. Étonnamment, cette opération constitue un véritable goulot d’étranglement pour le logiciel. « La conception est inefficace », a déclaré Steinhardt au public.

Chaque fois qu’un programmeur valide un changement de code, celui-ci est enregistré dans un fichier « packed-refs », ce qui permet de gagner du temps en ne donnant pas à chaque commit son propre fichier de référence.

Cependant, à mesure que les projets grandissent, il faut plus de temps à Git pour modifier ou supprimer une référence dans les références compressées (un dépôt GitLab contient un fichier références compressées de plus de 20 millions de références, a déclaré Steinhardt).

Cela est particulièrement problématique lorsque vous disposez de plusieurs lecteurs et rédacteurs simultanés de ce fichier. Et oubliez simplement d’avoir une vue cohérente de toutes les références.

La fonctionnalité Reftable récemment implémentée, qui sera la fonctionnalité par défaut dans Git 3.0, stocke les références dans un format binaire indexable. Les gens de Git ont emprunté ce concept à l’implémentation Java JGit de Git de la Fondation Eclipse.

Reftable permet des mises à jour en bloc, éliminant ainsi le besoin de réécrire un fichier de 2 Go pour une seule entrée. Et il est beaucoup plus rapide en lecture, ce qui ouvrirait la voie à la prise en charge par Git de référentiels plus grands et plus tentaculaires – parfait pour une main-d’œuvre agent toujours occupée.

Depuis près de deux décennies, Git s’est avéré être le système de contrôle de version de choix pour les geeks du monde entier. Mais même avec ces nouvelles fonctionnalités et diverses améliorations tierces, peut-il conserver sa pertinence pour une nouvelle génération de codeurs améliorés par des agents ?

La bataille est lancée. ®