{"schema_version":"1.0","service":"Publicasta","type":"article","id":959,"slug":"github_agent_scale_git_infrastructure_read_write_scaling","title":"La refonte de Git à l’échelle des agents par GitHub sépare les lectures des dépôts de la coordination des écritures","excerpt":"GitHub repense le stockage de GitHub.com à mesure que le développement piloté par des agents intensifie l’activité des dépôts. Pour les équipes, l’enjeu est de maîtriser la diffusion des écritures, les références sollicitées, les lectures CI et la gouvernance pendant la migration.","language":"fr","default_language":"en","canonical_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=fr","image":{"url":"https://publicasta.com/storage/projects/17/pages/959/2026/10/418e0579-8964-4938-8a97-720d1dd31b10.webp","alt":"Visualisation éditoriale d’une infrastructure cloud séparant la lecture des dépôts de la coordination des écritures Git."},"publisher":{"id":17,"slug":"it_today_news","name":"IT Today","url":"https://publicasta.com/it_today_news"},"author":{"name":"Anton R"},"published_at":"2026-10-24T13:39:14+00:00","updated_at":"2026-10-24T13:39:14+00:00","content_markdown":"GitHub reconstruit l’architecture de stockage qui sous-tend son service Git pour répondre à un modèle de développement où les humains, les systèmes d’intégration continue et les agents logiciels peuvent tous écrire simultanément dans les mêmes dépôts. Dans son dernier billet d’ingénierie, l’entreprise décrit une conception qui déplace les données persistantes des dépôts vers Azure Blob Storage, permet de faire évoluer séparément la capacité de lecture et réduit la coordination des écritures : elle ne s’effectue plus au niveau du dépôt, mais au niveau des références Git qui doivent réellement être ordonnées.\n\n ![Visualisation éditoriale d’une infrastructure cloud séparant la lecture des dépôts de la coordination des écritures Git.](https://publicasta.com/storage/projects/17/pages/959/2026/10/418e0579-8964-4938-8a97-720d1dd31b10.webp)\n\n Il s’agit d’un changement d’infrastructure important, pas d’une nouvelle fonctionnalité que les utilisateurs pourraient activer. GitHub présente ce chantier comme une reconstruction progressive menée alors que la plateforme reste en production. Selon le billet de suivi, l’entreprise a déjà transféré vers Azure des copies de 99,99999 % de ses dépôts, tandis que les cas restants nécessitent des modifications du protocole d’écriture. Les billets font également état d’améliorations du débit en interne, mais ils ne publient pas suffisamment de détails sur les benchmarks pour que ces chiffres puissent être considérés comme une garantie de capacité pour une entreprise ou une flotte d’agents donnée.\n\n Pour les équipes plateforme, la question immédiate n’est donc pas de savoir si un dépôt deviendra soudainement 35 fois plus rapide. Il faut plutôt concevoir les charges de travail de développement automatisé de façon à ne pas dépendre de la transformation de chaque point de contrôle en push, du partage d’une même référence très sollicitée par toutes les branches, ou du clonage répété des mêmes données par chaque tâche de CI.\n\n ## Ce que GitHub est en train de modifier\n\n L’architecture actuelle de GitHub, décrite dans la série d’articles d’ingénierie de l’entreprise sous le nom de Spokes, conserve des copies complètes des dépôts sur des nœuds de stockage et utilise une coordination des écritures fondée sur un quorum. Cette conception assure durabilité et cohérence, mais elle lie plusieurs tâches différentes. Le même ensemble général de répliques participe à la durabilité des écritures, sert les lectures Git et prend en charge des opérations de maintenance comme la compaction et le garbage collection.\n\n Cette interdépendance devient plus coûteuse lorsque l’activité augmente dans plusieurs directions à la fois. Un agent peut créer des commits ou des points de contrôle bien plus souvent qu’un développeur humain. Une vaste flotte d’agents peut créer de nombreuses branches dans un même dépôt. La CI peut multiplier les lectures à partir de la tête d’une branche après chaque modification. Les files de fusion et l’automatisation des livraisons peuvent ensuite concentrer les écritures sur un petit nombre de références.\n\n La refonte de GitHub repose sur deux principes liés : ne coordonner que ce qui doit l’être et séparer le stockage persistant du calcul qui traite les requêtes.\n\n Le premier principe s’applique à la mise à jour d’une référence lors d’un push Git. Un dépôt Git contient des objets immuables identifiés par leur contenu, ainsi que des références modifiables, comme les pointeurs de branches et de tags. C’est la mise à jour de la référence qui doit être ordonnée : dès qu’un client observe une nouvelle valeur pour une référence, les lectures suivantes ne doivent pas renvoyer une valeur plus ancienne. De nombreuses autres opérations liées à un push, notamment le stockage des objets, la validation de la connectivité, l’analyse des secrets et la maintenance, peuvent être exécutées en parallèle ou déplacées hors du chemin étroit qui mène à l’accusé de réception.\n\n Le second principe transforme l’usage des copies de dépôts. Au lieu d’exiger que chaque processus chargé de servir les lectures soit également une réplique persistante complète, GitHub décrit un modèle dans lequel Azure Blob Storage devient la source persistante et où des processus légers fournissent une capacité de lecture mise en cache. La défaillance d’un processus ressemble alors davantage à une perte de cache ou de calcul qu’à la perte de la copie de référence du dépôt. De nouveaux processus peuvent être ajoutés lors des pics de lectures sans augmenter automatiquement le même coût pour chaque écriture.\n\n L’architecture est déployée progressivement. Les billets de GitHub présentent les répliques virtuelles, les processus adossés au stockage, la sérialisation par référence et la maintenance en arrière-plan comme les éléments d’une migration, et non comme le lancement ponctuel d’un produit achevé.\n\n ## Pourquoi les charges de travail des agents ont révélé l’ancien goulot d’étranglement\n\n Le changement est souvent présenté comme une histoire d’« infrastructure IA », mais la pression sous-jacente est plus précise : le développement logiciel à haute concurrence produit une répartition différente des opérations Git.\n\n Un développeur humain peut travailler plusieurs minutes avant de créer un commit et de pousser une branche. Un agent automatisé peut enregistrer un point de contrôle après chaque tâche, lancer des tests, réviser des fichiers, puis recommencer le cycle. Des milliers d’agents travaillant sur une même base de code peuvent ainsi générer de nombreuses écritures, lectures, tentatives de fusion et mises à jour d’état concurrentes. Pour que cela devienne un problème, les agents n’ont pas besoin d’être autonomes au sens large. Une boucle de codage scriptée, connectée à un modèle, peut exercer la même pression sur l’infrastructure si elle effectue fréquemment des opérations sur les dépôts.\n\n GitHub indique que l’activité Git mensuelle est passée de 218,2 milliards d’événements en septembre 2025 à 473,3 milliards en août 2026. L’entreprise fait également état de 7,38 milliards de commits en septembre, de 3,35 milliards de pushes mensuels, d’une croissance presque quadruple du nombre de fusions de pull requests et de 3,26 milliards d’exécutions de GitHub Actions au cours de ce mois. Ces chiffres décrivent l’activité totale de la plateforme, et non une mesure précise de l’activité imputable aux seuls agents. Ils englobent le travail classique des développeurs, la CI, l’automatisation et la croissance du nombre de clients. Ils montrent néanmoins pourquoi un service de dépôts conçu pour un niveau de concurrence inférieur est réévalué.\n\n La pression ne concerne pas uniquement les écritures. Un dépôt comptant de nombreux agents ou processus de CI peut recevoir une vague de fetchs, de clones, de requêtes d’état et d’opérations sur les pull requests après chaque mise à jour de branche. Si la capacité de lecture dépend des mêmes répliques complètes que celles qui participent au quorum d’écriture, augmenter les lectures peut rendre les écritures plus coûteuses. Si un dépôt a besoin de nombreuses répliques supplémentaires pour absorber un pic de lecture, celles-ci peuvent accroître le travail de coordination et de maintenance, même lorsque le schéma d’écriture n’a pas changé.\n\n La refonte vise à rompre cette boucle de rétroaction. Les workers de lecture peuvent être dimensionnés selon la demande, tandis que l’état durable du dépôt et les mises à jour ordonnées des références restent dans une couche distincte. Cela ne rend pas chaque opération Git peu coûteuse et ne supprime pas le besoin de cohérence. Le changement porte sur l’endroit où le système dépense son budget de coordination.\n\n ## La coordination par référence est le détail de conception essentiel\n\n Le détail technique le plus utile de la dernière explication de GitHub est le passage d’une coordination à l’échelle du dépôt à une sérialisation par référence.\n\n Avec un verrou à l’échelle du dépôt, ou un chemin d’écriture équivalent sérialisé, deux pushes peuvent se gêner même s’ils mettent à jour des branches sans rapport. Un push vers `feature/alice` attend derrière un push vers `feature/bob`, car le dépôt est l’unité au niveau de laquelle le système coordonne la mise à jour. Cette approche est simple à comprendre, mais son débit est limité par la réplique la plus lente, par les allers-retours réseau nécessaires au quorum et par le nombre d’écritures pouvant traverser la file partagée.\n\n La sérialisation par référence réduit le domaine de conflit. Les mises à jour d’une même branche doivent toujours être ordonnées. Deux force-pushes vers la même référence ne peuvent pas être traités comme indépendants, car leur état final dépend de l’ordre et de la politique appliquée. En revanche, les mises à jour de branches différentes peuvent s’exécuter en parallèle si elles ne contreviennent pas aux règles de cohérence de Git ni à la gouvernance du dépôt.\n\n GitHub affirme que des tests internes de cette nouvelle approche ont montré que les écritures vers des références différentes atteignaient un débit environ 3 à 4 fois supérieur, avec une latence moindre, dans le scénario de migration décrit par l’entreprise. Ce résultat est plus précis que le chiffre plus général d’un « débit d’écriture jusqu’à 35 fois supérieur » cité dans le précédent article sur l’architecture, mais les deux restent des mesures internes. Les documents publiés ne précisent pas suffisamment la taille des dépôts, le niveau de concurrence, la composition de la charge, le matériel de référence, les percentiles de latence ou le déploiement en production pour permettre à une équipe externe de convertir directement ces chiffres en formule de dimensionnement.\n\n Cette distinction compte pour la planification technique. Un dépôt comportant des milliers de branches indépendantes à courte durée de vie peut tirer parti de la réduction de la contention. En revanche, une charge dans laquelle des milliers de workers mettent tous à jour une même branche partagée, une même balise de version ou une même file de fusion conserve une référence très sollicitée. La coordination par référence limite les conflits entre opérations sans lien ; elle ne rend pas un flux ordonné unique parallélisable à l’infini.\n\n ## Stockage durable et montée en charge des lectures\n\n Le modèle d’objets adressés par contenu de Git permet de séparer les données immuables de l’état mutable des références. Une fois qu’un objet a été stocké et validé, son identité est dérivée de son contenu. La partie changeante du dépôt est relativement réduite : les références se déplacent, et le système doit garantir aux clients une séquence cohérente avec ces déplacements.\n\n GitHub décrit Azure Blob Storage comme la couche durable destinée aux données des dépôts et présente un réplica virtuel d’écriture qui diffuse les écritures entrantes vers le stockage objet. L’écriture n’est confirmée qu’une fois les données persistées durablement dans cette couche. De légers réplicas de lecture peuvent ensuite réchauffer leurs caches depuis le stockage objet et servir le trafic de lecture sans participer au quorum d’écriture de la même manière qu’un réplica durable complet.\n\n L’avantage ne tient pas simplement au fait que « le stockage cloud est plus rapide ». Le stockage objet et les ressources de calcul dédiées au service peuvent être provisionnés et rétablis différemment. Il est possible d’ajouter un worker de lecture lorsqu’une mise en production, une dispersion des tâches CI ou une flotte d’agents génère de la demande. Un worker de lecture défaillant peut être remplacé et reconstituer son cache. La maintenance du stockage peut être effectuée par des workers distincts, sans entrer directement en concurrence avec les fetch et push actifs sur les mêmes machines.\n\n Cette approche comporte des compromis. Un worker de lecture nouvellement créé peut commencer avec un cache froid. La réconciliation depuis le stockage durable doit rester correcte en présence de mises à jour concurrentes. Certaines lectures peuvent exiger un état des références plus récent que d’autres ; la synchronisation en arrière-plan peut donc ne pas suffire. GitHub indique que les prochaines étapes déplaceront davantage de réconciliation dans le chemin de requête, afin qu’un réplica puisse récupérer l’état de référence ainsi que les données modifiées depuis sa dernière mise à jour complète.\n\n L’architecture déplace donc le problème au lieu de le supprimer. Plutôt que de demander à chaque réplica complet de participer à chaque opération, le système doit gérer la fraîcheur des caches, l’état durable des références, la reprise, la compaction et les frontières entre service et maintenance. Le modèle est séduisant parce que ces responsabilités peuvent être dimensionnées séparément, mais cette indépendance exige aussi des règles de cohérence explicites et une observabilité solide.\n\n ## Le chiffre de « 35 fois » doit être interprété avec prudence\n\n Dans un article précédent, GitHub affirme que l’architecture reconstruite a atteint jusqu’à 35 fois plus de débit d’écriture lors de benchmarks internes. C’est un signal utile sur l’orientation du travail, mais cela ne signifie pas qu’un dépôt client bénéficiera d’une amélioration multipliée par 35.\n\n La publication accessible au public ne décrit pas la configuration du benchmark avec suffisamment de précision pour déterminer où ce chiffre s’applique. Elle ne fournit ni la taille du dépôt, ni le nombre de références, ni le niveau de concurrence, ni la répartition des écritures, ni le ratio lectures-écritures, ni le système de référence, ni la distribution de la latence, ni les conditions de défaillance ; elle ne précise pas non plus si le benchmark reproduit le trafic de production. Elle n’indique pas davantage que tous les dépôts ont migré vers le nouveau chemin, ou que la mesure correspond à une limite de service généralement disponible.\n\n La même prudence s’impose pour les statistiques d’activité de l’entreprise. La croissance rapide du nombre de push et de commits montre que la plateforme subit une pression accrue, mais elle ne prouve pas que les agents sont à l’origine de toute cette hausse. Elle ne montre pas non plus que davantage d’opérations Git produisent proportionnellement davantage de logiciels utiles. Un grand nombre de points de contrôle automatisés peut correspondre à un travail parallèle productif, à une activité superflue, à des tentatives répétées, ou à un mélange des trois.\n\n La conclusion opérationnelle est simple : ne dimensionnez pas une plateforme d’agents en multipliant la concurrence actuelle par le chiffre mis en avant dans le benchmark. Considérez plutôt ce benchmark comme le signe que GitHub s’attaque à un goulot d’étranglement structurel, puis mesurez votre propre charge à travers la latence des push, les push refusés ou relancés, les limites de débit de l’API, le temps passé en file d’attente, la dispersion des tâches CI et le délai jusqu’à la fusion.\n\n ## Ce que cela signifie dès maintenant pour les équipes d’ingénierie\n\n Les utilisateurs n’ont pas besoin de réécrire leurs workflows Git habituels à la suite de cette annonce. L’objectif affiché par GitHub est de préserver les branches, les revues, les fusions, l’historique, la protection des branches, les revues obligatoires, les journaux d’audit, la visibilité des dépôts et les autres contrôles, tout en modifiant le backend qui les prend en charge.\n\n Les équipes qui exécutent beaucoup d’automatisations devraient néanmoins réexaminer la conception de leurs charges de travail. Cette analyse reste utile même si la migration de GitHub finit par réduire une grande partie de la pression actuelle, car elle diminue le travail gaspillé et facilite la reprise après échec.\n\n ### Réduire la fréquence des push inutiles\n\n Un agent n’a pas besoin de pousser chaque point de contrôle intermédiaire vers une branche distante partagée. Conservez autant que possible les points de contrôle en local pendant une tâche, puis poussez les étapes importantes ou un lot de modifications de taille limitée. La fréquence appropriée dépend des exigences de reprise et du coût de la perte du travail local, mais une politique qui transforme chaque appel d’outil en push distant génère du trafic d’écriture évitable.\n\n Pour les tâches de longue durée, conservez les points de contrôle locaux ou externes séparément de la mise à jour de la branche si l’équipe a besoin d’une récupération fine. Le besoin de reprise durable reste ainsi distinct de la référence Git que les autres développeurs et systèmes doivent consulter.\n\n ### Éviter de créer une référence unique très sollicitée\n\n Des milliers de branches indépendantes peuvent malgré tout converger vers une branche protégée, une étiquette de version ou une file de fusion. Identifiez les références qui reçoivent le plus grand nombre d’écritures ainsi que les workflows qui se sérialisent sur ces références. Un dépôt peut offrir un excellent parallélisme global entre les branches, tandis qu’une référence partagée reste le véritable goulot d’étranglement.\n\n Utilisez des files de fusion et des regroupements contrôlés lorsqu’ils améliorent l’ordonnancement, mais surveillez l’ancienneté de la file et le comportement des nouvelles tentatives. Une file qui recalcule ou revalide sans cesse le même ensemble volumineux de modifications peut déplacer la pression des écritures Git vers la CI, les API des pull requests ou l’infrastructure de test.\n\n ### Rendre les lectures de la CI intentionnelles\n\n L’automatisation fortement orientée vers la lecture peut submerger un dépôt même lorsque le volume de push reste modéré. Privilégiez les clones superficiels ou partiels lorsque le workflow le permet, réutilisez les caches du dépôt, évitez les clones complets répétés pour des entrées identiques et répartissez les traitements lorsqu’une version ou une mise à jour de branche déclenche de nombreux jobs simultanément.\n\n Les recommandations de GitHub pour les dépôts conseillent de rester dans certaines limites opérationnelles, notamment une taille de push de 2 Go, un plafond recommandé de 15 opérations de lecture Git par seconde et par dépôt, ainsi qu’un rythme recommandé de six pushs par minute et par dépôt. Ces repères ne remplacent pas la planification de capacité et ne décrivent pas toutes les configurations d’API ou d’entreprise, mais ils rappellent qu’un dépôt constitue une frontière de service partagée. Les clients automatisés devraient considérer les limites publiées comme des paramètres de conception, plutôt que de les découvrir par la limitation de débit.\n\n ### Empêcher les nouvelles tentatives d’amplifier un incident\n\n Un échec de push ou de récupération peut amener une vaste flotte d’automatisation à réessayer au même moment. Utilisez un délai exponentiel avec une part d’aléa, plafonnez le nombre de tentatives, distinguez les erreurs de transport transitoires des échecs liés aux politiques et enregistrez l’identifiant de l’opération initiale ou la plage de commits afin qu’une nouvelle tentative ne crée pas de travail en double.\n\n La stratégie de nouvelle tentative doit aussi respecter la revue humaine. Si un workflow attend la mise à jour d’une branche protégée, des tentatives aveugles peuvent inonder la même référence pendant qu’un opérateur mène son investigation. Le délai d’attente progressif est un mécanisme de fiabilité, pas seulement un réglage de performance côté client.\n\n ### Préserver la gouvernance malgré l’automatisation croissante\n\n GitHub indique que la nouvelle infrastructure doit préserver les protections de branches, les revues obligatoires, les journaux d’audit et la visibilité des dépôts. Les organisations devraient vérifier que leurs propres workflows d’agents s’appuient explicitement sur ces contrôles. Un chemin d’écriture plus rapide ne remplace ni les règles d’approbation, ni l’analyse des secrets, ni les commits signés lorsqu’ils sont requis, ni la protection des environnements, ni les contrôles de déploiement.\n\n Les agents devraient disposer uniquement des autorisations nécessaires sur les dépôts et les environnements pour accomplir leur tâche. Séparez l’accès à la génération de code de l’autorité de fusion, des identifiants de déploiement et des données de production. Si un agent peut créer des branches, mais ne peut pas mettre à jour la branche par défaut protégée sans revue, les améliorations de montée en charge de la plateforme augmentent le débit sans supprimer discrètement le point de décision humain.\n\n ## Ce qui reste inconnu\n\n Plusieurs questions importantes restent ouvertes dans la description publique de GitHub.\n\n L’entreprise n’a pas publié de calendrier complet de déploiement de la nouvelle architecture. Elle n’a pas indiqué combien de dépôts de production sont servis par le modèle de lecture adossé au stockage, quelles charges de travail sont éligibles ni quand les clients devraient constater des changements mesurables au niveau des limites et de la latence.\n\n Les résultats annoncés dans les benchmarks nécessitent également davantage de contexte. Les lecteurs externes ont besoin des définitions des charges de travail, de la taille des dépôts, des niveaux de concurrence, des latences p50 et p99, du comportement en cas d’échec et de comparaisons avec le chemin existant. Sans ces précisions, la formulation « jusqu’à » constitue un signal d’ingénierie utile, mais pas une garantie pour la planification.\n\n La cohérence pendant le réchauffement du cache est un autre point à surveiller. Un worker qui restaure son état depuis un stockage objet ne doit pas renvoyer des valeurs obsolètes de références d’une manière qui contredise les attentes de Git. Le système doit également gérer la compaction, le ramasse-miettes, les écritures interrompues, les délais interrégionaux et la reprise après des défaillances partielles, sans transformer la maintenance en nouveau goulot d’étranglement pour le service.\n\n Enfin, le lien entre l’activité des agents et la croissance annoncée de la plateforme reste en partie non mesuré. Les statistiques de GitHub regroupent les développeurs humains, l’automatisation classique, la CI et les flux de travail pilotés par des agents. Cela suffit à justifier un travail architectural, mais pas à conclure que toutes les organisations connaîtront le même niveau de concurrence.\n\n ## Ce qu’il faut retenir de l’annonce\n\n GitHub répond à une évolution réelle de la forme que prend le développement logiciel : davantage d’opérations sur les dépôts, plus de branches concurrentes, davantage de lectures automatisées et une pression accrue sur les points d’intégration partagés. La réponse de l’entreprise consiste à réduire la coordination superflue, à séparer le stockage durable des capacités de service et, lorsque c’est possible, à rendre la capacité de lecture indépendante du quorum d’écriture.\n\n Pour les clients, la leçon immédiate concerne la discipline des charges de travail. Évitez que l’état intermédiaire des agents ne se transforme en activité Git distante incessante, repérez les références très sollicitées, maîtrisez la dispersion des appels de CI, mettez en cache les lectures répétées et rendez les nouvelles tentatives moins agressives. Continuez à faire respecter les limites de revue et de déploiement, même si l’automatisation gagne en capacité.\n\n Cette architecture pourrait à terme offrir à GitHub une marge de manœuvre nettement plus importante, mais les benchmarks publiés ne dispensent pas de mesurer les charges réelles. Pour une équipe plateforme, la question utile n’est pas de savoir si GitHub a annoncé un multiplicateur impressionnant. Il faut déterminer quelle partie de la boucle de développement de l’équipe est actuellement sérialisée, si cette sérialisation est nécessaire et ce qui se produira lors de la prochaine vague de travail automatisé.","available_translations":[{"language":"ar","title":"إعادة بناء Git لدى GitHub على نطاق الوكلاء تفصل بين قراءة المستودعات وتنسيق الكتابة","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=ar","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=ar","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=ar"},{"language":"de","title":"GitHubs Git-Neuaufbau für agentenbasierte Skalierung trennt Repository-Lesezugriffe von der Schreibkoordination","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=de","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=de","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=de"},{"language":"en","title":"GitHub’s Agent-Scale Git Rebuild Separates Repository Reads from Write Coordination","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=en","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=en","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=en"},{"language":"es","title":"La reconstrucción de Git de GitHub a escala de agentes separa las lecturas del repositorio de la coordinación de escrituras","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=es","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=es","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=es"},{"language":"fr","title":"La refonte de Git à l’échelle des agents par GitHub sépare les lectures des dépôts de la coordination des écritures","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=fr","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=fr","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=fr"},{"language":"pl","title":"GitHub przebudowuje Git na skalę agentów, oddzielając odczyty repozytoriów od koordynacji zapisów","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=pl","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=pl","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=pl"},{"language":"ru","title":"GitHub перестраивает Git-инфраструктуру под нагрузку от агентов, разделяя чтение репозиториев и координацию записи","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=ru","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=ru","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=ru"},{"language":"zh","title":"GitHub 面向代理规模重建 Git 基础设施，将仓库读取与写入协调分离","html_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=zh","markdown_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=zh","json_url":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=zh"}],"_links":{"self":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=fr","api":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/github_agent_scale_git_infrastructure_read_write_scaling?lang=fr","html":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=fr","canonical":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling?lang=fr","markdown":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.md?lang=fr","json":"https://publicasta.com/it_today_news/github_agent_scale_git_infrastructure_read_write_scaling.json?lang=fr","channel":"https://publicasta.com/api/public/v1/channels/it_today_news","channel_articles":"https://publicasta.com/api/public/v1/channels/it_today_news/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}