Mise à jour du 15 octobre pour inclure plus de détails sur les projets qui ont été les pionniers de nombreuses techniques que nous utilisons dans Scion.
Chez Anthropic, le codage n'est plus le goulot d'étranglement pour construire des systèmes ou mener des recherches. Claude est capable d'itérer de manière autonome sur des boucles de recherche, de micro-optimiser des programmes complexes et de construire de nouveaux services de A à Z à une vitesse et à une échelle que nous n'avions jamais vues. Le goulot d'étranglement, désormais, ce sont toutes les infrastructures de développement conçues pour l'échelle humaine : gestion de code source, builds et CI.
En mai 2026, Anthropic fusionnait en moyenne environ 2,500 changements de code par jour ; à compter de septembre, nous avons fusionné plus de 30,000 changements par jour. Nous ne nous attendons pas à ce que ce rythme de croissance ralentisse de sitôt ; la demande latente de fusion de code est pratiquement infinie, et chaque goulot d'étranglement que nous supprimons entraîne immédiatement une nouvelle augmentation de la quantité de code que nous produisons.
Pour soutenir cette croissance, nous avons construit Scion, un système de gestion de versions développé en interne, et avons entièrement migré notre monorepo depuis git en cinq mois. Nous avons également construit et livré une interface de revue de code (appelée Antique), une recherche de code, un système IAM riche pour le code source, de nouvelles façons de gérer et d'intégrer de grandes quantités de code révisé, et plus encore, le tout durant cette même période. Dans cet article, nous nous concentrerons spécifiquement sur la façon dont nous avons construit Scion. Cela constitue une étude de cas intéressante : la capacité de Claude à écrire du code est à la fois ce qui nous a mis dans cette situation en premier lieu et ce qui nous a permis de construire rapidement un système de qualité, évolutif, pour y faire face.
Faire grandir notre monorepo
Avant d'explorer ce que nous avons construit, nous devons reconnaître à quel point notre charge de travail est inhabituelle. Sans surprise, Anthropic utilise Claude pour écrire des logiciels bien plus que presque toute autre entreprise, si bien que nous sommes souvent les premiers à voir où les outils conçus pour l'échelle humaine commencent à montrer leurs limites. La gestion du code source n'est qu'un exemple parmi d'autres. Bien que nous ne nous attendions pas à ce que de nombreuses organisations rencontrent ces problèmes dans un avenir très proche, nous suspectons qu'il ne faudra pas longtemps avant que d'autres utilisateurs d'outils de codage par IA n'éprouvent ces mêmes points de pression, c'est pourquoi nous voulions partager ce que nous avons construit et ce que nous avons appris.
Git est un système décentralisé : chaque clone est un dépôt complet et autonome capable de calculer des diffs, de lire l'historique et le blame, et de vérifier n'importe quelle révision en étant entièrement hors ligne. Pour la grande majorité des dépôts, c'est le bon choix de conception, et c'est en grande partie la raison pour laquelle git est devenu la norme.
À mesure que notre monorepo grandit, il correspond de moins en moins à cet espace de conception. L'historique de notre branche principale seule fait presque 100 GB, et une copie de travail compressée dépasse 25 GB. Nous effectuons de l'ordre de 25 millions d'extractions de code par jour pour la CI, sans compter les environnements de développeurs, les sandbox d'agents et les tâches de recherche. Récupérées de manière naïve, cela représenterait plus de 600 PB de trafic git par jour.
Git offre des outils pour travailler avec une portion d'un dépôt, tels que les clones superficiels, les extractions partielles (sparse checkouts) et les promisor remotes. Au-delà de cela, il existe des solutions de contournement standards pour les grands monorepos, comme les miroirs git internes et les instantanés de dépôts (seeds) conservés dans un stockage d'objets. Nous avons tout utilisé — à notre pic, nous exploitions plusieurs centaines de miroirs git internes pour gérer la charge. Cela nous a acheté du temps, mais ces solutions sont devenues plus difficiles à exploiter à mesure que notre taux de fusion augmentait. Les seeds prenaient de plus en plus de retard par rapport à la pointe de main entre les rafraîchissements, et il fallait de plus en plus de soin pour maintenir fonctionnelles, sur des clones partiels, les opérations qui dépendent de l'historique, comme diff et blame.
En prenant du recul, nous avons remarqué que, comme la plupart des entreprises, nous utilisions git comme un système centralisé avec une seule copie faisant autorité, mais que presque tous nos clients étaient des agents et des tâches qui, par définition, sont en ligne. Les propriétés qui rendent git excellent pour le travail distribué et hors ligne sabotaient activement notre capacité à évoluer à mesure que le dépôt grandissait. Nous nous sommes donc posé la question : si nous concevions la gestion de code source en intégrant dès le départ le fait que les agents sont toujours en ligne, à quoi cela ressemblerait-il ?
Principes pour une gestion de code source à l'échelle des agents
Avec le codage agentique, de nombreuses hypothèses courantes sur la façon dont les logiciels sont développés évoluent. Nous avons embrassé ces changements lors de la construction de Scion, ce qui nous a permis d'adopter une approche fondamentalement différente de git sur plusieurs principes fondamentaux. La gestion de code source pour d'immenses monorepos a des précédents, notamment Piper de Google et Sapling,2 de Meta, si bien que nous avons pu construire Scion en gardant à l'esprit leurs leçons durement acquises. Nos principes sont :
Les clients sont toujours en ligne. Git suppose que les clients travaillent hors ligne et ont besoin d'une copie complète du dépôt. Comme presque tous nos clients sont des agents et des tâches, nous avons conçu le client et les protocoles de Scion autour d'un serveur toujours joignable, les clients récupérant les données quand ils en ont besoin.
Asymétrie client-serveur. Dans git, chaque client est capable d'être un serveur à part entière. Dans Scion, le serveur répond aux questions sur l'historique des fichiers et le blame, crée des commits, effectue des fusions et des rebases, et ainsi de suite. Le client maintient un cache local d'objets de taille limitée, dispose les fichiers de la copie de travail sur le disque, surveille les modifications du système de fichiers et offre aux utilisateurs un moyen ergonomique de travailler avec le serveur. Il peut calculer très peu de choses par lui-même mais, en échange, il nécessite beaucoup moins de données localement.
Un service de gestion de versions complet peut alimenter de nombreuses applications inédites. Avec git, une tâche CI ou un outil qui doit poser une question sur le dépôt, comme savoir qui a modifié en dernier une ligne ou comment deux commits sont liés, doit maintenir une copie locale du dépôt ou espérer que des API spécifiques au fournisseur fournissent la réponse. Avec Scion, toutes les requêtes de gestion de versions utilisées par le client sont également exposées via une API, si bien que dans de nombreux cas les tâches n'ont pas besoin du tout d'un dépôt local. De nombreux outils internes, comme nos pipelines automatisés de bisect et de revert, ne seraient pas praticables à grande échelle sans cet accès programmatique peu coûteux à la gestion de versions.
Tout doit être évolutif horizontalement. À notre pic, nous exécutions plusieurs centaines de miroirs git, ce qui sollicitait fortement la capacité et ne passait plus à l'échelle une fois que le dépôt avait dépassé les limites de disque ou de mémoire des miroirs. Dans Scion, les données du dépôt sont distribuées et chaque composant évolue indépendamment ; il n'existe nulle part de copie entièrement matérialisée du dépôt, pas même sur le serveur. Il n'y a pas d'équivalent des packfiles (les paquets compressés d'objets de git), donc aucune maintenance du dépôt n'est nécessaire.
Les commits doivent être peu coûteux, incrémentaux et sans verrouillage. Dans git, on committe localement puis on pousse pour partager son travail. Dans Scion, chaque commit, rebase ou merge se produit sur le serveur, il n'y a donc rien à pousser, mais chacune de ces opérations doit être rapide. Le coût de création d'un commit et de mise à jour de ses structures de données en aval doit évoluer avec la taille du changement, et non avec la taille globale du dépôt, sinon le serveur ne peut pas suivre. Le cycle de développement dans Scion déconseille les refs (pointeurs vers des commits, comme les branches et les tags), à l'exception de la ref principale ou des branches de release, car l'état global sur lequel chaque serveur doit s'accorder constitue un problème d'évolutivité menaçant.
La copie de travail est optionnelle et clairsemée par conception. Comme notre monorepo est si vaste, et comme nous effectuons des dizaines de millions de checkouts de code par jour pour la CI, nous voulions éviter les checkouts autant que possible. Avec Scion, une tâche CI qui a besoin du diff entre un commit et sa base de merge, par exemple, peut le demander au serveur. Il en va de même pour les écritures : de nombreuses charges de travail en écriture peuvent également se passer du checkout et fonctionner entièrement via l'API. Le protocole de Scion est centré sur les checkouts clairsemés, qui ne contiennent que les répertoires demandés par le client, et les checkouts virtualisés, qui matérialisent les fichiers à la demande ; ainsi, lorsqu'une tâche a besoin de fichiers sur disque, le client ne paie que ce qu'il lit réellement.
Comment fonctionne Scion
Il est utile de comprendre comment ces principes se sont concrétisés dans la pratique lors de la construction de Scion. Ces enseignements peuvent s'appliquer à d'autres systèmes de gestion de versions ou, plus largement, à d'autres étapes du cycle de développement logiciel.
Structures de données
Dans Scion, l'unité de travail est un « changeset », une entrée dans un journal à écriture anticipée. Un changeset stocke la plupart de ce à quoi on s'attend d'un commit dans git. Mais là où un commit git stocke un pointeur vers l'arbre, un changeset stocke une liste des fichiers modifiés par rapport à son premier parent,1 accompagnée de pointeurs adressés par contenu vers les contenus de fichiers compressés dans le stockage de blobs. Les changesets sont créés côté serveur et sont disponibles partout, instantanément.
Cette structure nous permet d'accepter des changesets avec un très haut débit car il n'y a aucun packfile à accepter, aucun verrouillage ni coordination entre serveurs, et aucune ref à déplacer. Scion prend techniquement en charge les refs, mais comme ni la création ni la récupération de commits n'y font appel, en déplacer une est un compare-and-swap sur une seule ligne Spanner qui se produit séparément de la création des changesets.
Un changeset n'enregistre que ce qui a changé, donc à lui seul, il ne peut pas répondre rapidement à des questions comme savoir qui a modifié en dernier une ligne ou quels commits ont affecté un fichier. Pour y répondre, Scion construit des structures de données supplémentaires à partir des changesets, notamment des structures dédiées pour le file blame et l'historique des chemins, ainsi que des skip lists pour le graphe des commits. Nous appelons « données dérivées » tout ce qui ne fait pas directement partie du changeset, et nous les calculons toutes via un mécanisme générique. Chaque type de données dérivées est défini récursivement, de sorte que sa valeur pour un changeset est calculée à partir de ses valeurs pour les parents de ce changeset.
Ce mécanisme présente trois avantages. Premièrement, nous pouvons facilement ajouter un nouveau type de données dérivées lorsqu'une nouvelle structure de données rendrait une opération plus rapide. Deuxièmement, pour chaque type, nous pouvons choisir de le calculer de manière anticipée ou de différer le travail, ce qui nous évite de matérialiser des données dont nous n'avons pas besoin. Et troisièmement, comme le client ne voit jamais les internes de ces structures de données, nous pouvons les optimiser sans modifier le client. Nous avons ajouté de nouveaux types de données dérivées à de nombreuses reprises au fil de la croissance du système, comme de nouveaux index pour effectuer la détection de copies ou la recherche de fichiers par chemin.
Faire évoluer Scion
Une petite flotte de serveurs Scion fournit des API de gestion de versions pour toute opération dont un client a besoin, comme récupérer des changesets, calculer des diffs, trouver des bases de merge et extraire des blobs. Toutes les données de gestion de versions sont adressées par contenu, de sorte qu'une donnée ne change jamais une fois stockée, et n'importe quel serveur peut la mettre en cache sans vérifier auprès des autres. Par conséquent, les serveurs sont évolutifs horizontalement et nécessitent peu de coordination. Ce sont essentiellement de grands caches qui peuvent également calculer des données dérivées à la volée et réécrire les résultats dans Spanner.
Les nombreux consommateurs de Scion n'ont plus besoin de maintenir leurs propres dépôts locaux. Récupérer et maintenir le dépôt représentait auparavant une charge de maintenance importante pour les jobs CI ou les outils qui devaient poser des questions au contrôle de source, notamment sur l'ascendance des commits et le blame. Au début de la migration, avant que nous ayions notre propre client, format de dépôt ou protocoles, Scion ne répondait qu'à ces requêtes de « métadonnées ». La récupération du contenu des fichiers et la matérialisation de copies de travail sont des opérations bien plus gourmandes en données, et elles nécessitaient une conception qui leur soit propre.
Le client scn de Scion s'écarte des protocoles de fetch de git de plusieurs manières importantes et, par conséquent, se prête à une architecture hautement évolutive qui requiert nettement moins de CPU que les serveurs git. La négociation de Scion ne dit pas au serveur ce que le client possède déjà ; elle opère exclusivement sur les arbres et les blobs que le client veut. À partir d'un arbre racine, le client vérifie dans son magasin local les arbres manquants et les demande récursivement, puis répète le processus pour les blobs. Chaque requête porte sur un objet spécifique qui ne change jamais, de sorte que n'importe quel cache peut y répondre, et l'architecture ressemble étroitement à des caches hiérarchisés traditionnels. Le processus est également efficace et reprenable, car il n'y a pas de réponse unique sous forme de packfile de plusieurs gigaoctets. Les checkouts creux, voire virtualisés, n'ont pas besoin de support particulier, car le client ne demande simplement pas les arbres qu'il ne veut pas.
Dans la flotte, le client communique via un socket avec un démon, scion-daemon, qui stocke les objets pour l'ensemble du nœud. La plupart de nos nœuds ont besoin d'accéder au monorepo, et les jobs sur un même nœud réutilisent la plupart des mêmes objets. Chaque démon part d'un instantané actualisé périodiquement, puis ne communique qu'avec les serveurs de cache d'arbres et de blobs de sa région, appelés scion-cache. Ces serveurs de cache diffusent les objets directement depuis la mémoire, dans le format disque que le démon consommera, de sorte qu'ils n'ont pas besoin de passer du temps à calculer les objets manquants du client ni à effectuer de compression delta. Lorsqu'un cache manque d'un objet, il interroge les scion-servers faisant autorité, qui lisent dans Spanner ou le stockage cloud selon les besoins.
Le scion-daemon, le scion-cache et le scion-server répondent tous à des RPC identiques pour ce protocole, de sorte que le client n'a pas besoin de connaître la topologie des caches. N'importe quel niveau pourrait théoriquement communiquer avec n'importe quel autre, mais nous appliquons strictement la hiérarchie afin d'isoler les domaines de défaillance. Nous voulons éviter une situation où une défaillance d'un scion-cache régional submergerait les scion-servers en amont et ferait tomber tout le système.
Chaque niveau de ce système maintient un taux de succès de cache supérieur à 99% et ne nécessite pas d'état de longue durée, de sorte qu'il est facile de monter en charge si nécessaire. Notre empreinte d'infrastructure Scion est désormais 200x plus petite que notre précédente infrastructure de miroir git en termes de besoins en CPU et en mémoire. Les jobs de CI et de recherche extraient le code deux ordres de grandeur plus vite (en secondes plutôt qu'en minutes), ce qui libère une capacité considérable dans toute la flotte ; la CI à elle seule a permis un gain de capacité CPU de 25%. Ni les clients ni les caches n'ont besoin d'effectuer de maintenance du dépôt, ce qui simplifie la gestion du cycle de vie de nos jobs.
Ce que nous avons appris en construisant Scion
Nous avons commencé à construire Scion à peu près au moment où Claude Mythos Preview et Claude Tag sont devenus disponibles en interne. Ces deux versions ont simultanément amplifié le besoin de Scion et accéléré considérablement la vitesse à laquelle nous pouvions le construire.
Voici un exemple particulièrement frappant. Plus tôt dans l'année, nous avions largement écrit à la main la première version du pipeline d'ingestion git-vers-Scion en tant que prototype. Nous la trouvions bonne — jusqu'à ce que nous mettions la main sur un instantané interne précoce de Claude Mythos Preview. Nous lui avons demandé de réécrire l'ensemble, et sans instructions supplémentaires, il a produit une version qui consommait 20x moins de mémoire et était 4x plus rapide, tout en préservant tous les invariants implicites autour de l'ordre d'ingestion et des structures de données.
Ce que nous avons appris en construisant et en exploitant Scion offre des leçons intéressantes sur ce que pourrait être la construction de logiciels à l'échelle des agents.
Le développement rapide avec une petite équipe deviendra plus courant. Une équipe de sept personnes a construit à la fois Scion et Antique (notre outil de revue de code, sur lequel nous pourrions facilement écrire tout un autre article de blog), sans parler d'une demi-douzaine de systèmes connexes, et a entièrement migré vers eux en cinq mois. Nous avons fait tout cela alors que le volume de code fusionné par jour augmentait de 10x. Par le passé, développer et déployer un système de contrôle de source de ce type aurait pris des années de migration itérative pour une entreprise, avec beaucoup plus d'ingénieurs. Nous pensons que ce type de migration rapide et agile deviendra plus courant à l'avenir.
Les ingénieurs ne sont pas moins précieux, mais leur travail est en train de changer. Tous les ingénieurs qui ont travaillé sur ce système jugeraient aujourd'hui que Claude est meilleur qu'eux pour écrire du code. Mais nos ingénieurs ont toujours apporté la compréhension inestimable des composants inter-systèmes de haut niveau et des compromis de conception, en faisant des choix éclairés concernant les problèmes que nous voulions résoudre et l'échelle que nous savions devoir atteindre. Très souvent, nous avons constaté que le rôle des ingénieurs était de dire « non » à Claude. Les agents violent parfois les contraintes fondamentales du système pour satisfaire un modèle qui n'aurait jamais dû être autorisé en premier lieu. C'était particulièrement fréquent dans notre migration. Par exemple, plusieurs systèmes ont tenté de déterminer par force brute quand une modification avait été fusionnée dans main en lisant linéairement le journal des commits au lieu d'interroger notre outil de revue de code. Anthropic fait également un usage intensif de la revue adverse, et, bien que cette méthode soit incroyablement efficace à bien des égards, elle peut aussi être myope, si bien que des ingénieurs compétents devaient détourner Claude du sur-ingénierie de certaines parties du système en réponse à des préoccupations hypothétiques. Par exemple, une telle revue était trop défensive quant à la confiance accordée à un autre service interne, ce qui a conduit Claude à ajouter une validation et une complexité excessives. Les membres de notre équipe examinent toujours chaque demande de modification du système, mais ils analysent désormais l' intention de la modification au lieu de lire chaque ligne de code.
Nous avons pu améliorer considérablement l'optimisation et la qualité. Grâce à la capacité de Claude à écrire d'immenses quantités de code bien plus vite que nous ne pourrions le faire nous-mêmes, Scion figure parmi les bases de code les mieux testées et les mieux défendues sur lesquelles nous ayons jamais travaillé. Même avec notre calendrier serré, nous avons pu construire des simulations hermétiques de chaque interaction non triviale avec l'infrastructure et le contrôle de source que nous avons jamais rencontrées, ainsi que du fuzzing et une limitation de débit sophistiquée. Claude a aussi trouvé au passage des optimisations significatives — par exemple, une optimisation algorithmique des requêtes d'ascendance qui avait échappé à l'un de nos index — qui auraient demandé à un expert des jours ou des semaines d'analyse et de réglage… puis il a recommencé le lendemain.
Nous avons préparé le terrain pour de nouvelles formes de sécurité de monorepo. Gérer la sûreté, la sécurité et la conformité dans un monorepo massif est aussi important que de gérer la taille et l'échelle. Nous avons construit Scion en gardant ces aspects à l'esprit dès le départ. Il prend en charge un contrôle d'accès riche sur les dépôts, ainsi que la possibilité d'appliquer des permissions à des répertoires individuels afin de protéger le code le plus sensible sans perdre les avantages d'un monorepo. De plus, l'outillage de revue de code que nous avons construit peut exprimer des contraintes sémantiques complexes sur les approbations, ce qui nous permet de distinguer des choses simples comme les modifications limitées aux commentaires des modifications logiques sensibles, afin que les réviseurs humains puissent se concentrer sur les modifications les plus importantes.
Un nouveau niveau d'excellence opérationnelle est possible. Notre équipe utilise intensivement Claude Tag, ce qui nous a aidés à surveiller chaque composant du système. Par exemple, nous avons créé des canaux Slack où nous avons chargé Claude de se concentrer de manière obsessionnelle sur la santé d'un seul composant. Nous appelons ces Claudes des « superfans ». Nous avons un superfan de scion-daemon, un superfan de scion-cache, un superfan de la file de fusion Antique, et ainsi de suite. Ils ont accès à notre télémétrie et à nos journaux, et se comportent comme un ingénieur expérimenté qui n'aurait rien de mieux à faire que d'actualiser des graphiques et de chercher tout ce qui est étrange. Nous avons également des alertes traditionnelles pour tous nos systèmes, mais nos superfans peuvent détecter des problèmes subtils et inédits qui rendent ces alertes unidimensionnelles en comparaison.
Nous repensons complètement nos a priori. Ce projet nous a poussés à examiner de très près d'autres flux de travail conçus pour l'échelle humaine. Une véritable file de fusion, par exemple, n'a pas beaucoup de sens à l'échelle des agents. Que signifie même le CI lorsque des centaines, voire des milliers de modifications peuvent être fusionnées pendant que les tests s'exécutent ? Nous n'avons pas pu reproduire efficacement la norme de l'industrie d'un verrou global de dépôt sur la file de fusion, donc à la place, nous avons investi dans des tests automatisés post-fusion et pré-déploiement. Cela signifie que des modifications concurrentes peuvent entrer en conflit, mais Claude peut généralement corriger ces conflits plus vite que les humains ne peuvent même les identifier.
Contribuer à l'écosystème plus large
Nous considérons Scion comme une seule partie de la réponse aux préoccupations de passage à l'échelle que des agents d'IA de plus en plus capables ont soulevées. Nous partageons ces détails comme un exemple de la manière dont les équipes peuvent aborder des défis similaires, bien que nous ne nous attendions pas à ce que notre solution, ou nos réflexions, conviennent à chaque cas.
Scion n'est en aucun cas un remplacement approprié de git pour un usage général. Les concepts que nous avons présentés ici n'ont vraiment de sens que pour des monorepos véritablement énormes, comptant soit des dizaines de milliers d'ingénieurs, soit des essaims d'agents écrivant du code de façon prolifique. De plus, Anthropic est unique en ce sens que notre capacité à dépenser des jetons pour un usage interne dépasse de loin ce que toute autre entreprise voudrait raisonnablement dépenser. Nous faisons cela à la fois pour répondre à nos propres besoins de développement logiciel et pour tester les capacités de Claude.
En pratique, il est difficile de proposer Scion sous une forme qui serait largement utile à d'autres organisations. Il diverge considérablement de git, ce qui signifie que les entreprises devraient migrer chaque élément du cycle de développement, et il nécessite sa propre revue de code, sa propre recherche de code et son propre CI. Nos versions internes de ces composants sont hautement sur mesure, donc il serait difficile pour d'autres organisations de les adopter, et nous craignons que tenter de construire une version publique cherchant à plaire à tout le monde ne soit en réalité pas très utile.
Cependant, nous anticipons que cette classe de problèmes deviendra plus courante au cours des six à 12 prochains mois, et il serait inefficace que chaque entreprise utilisant git consacre ses ressources d'ingénierie à affronter seule des défis similaires. Pour cette raison, nous pensons que la chose la plus utile à faire est de partager notre réflexion, afin que d'autres développeurs puissent appliquer à git certaines des parties les plus réussies de Scion sans s'écarter du modèle général. Un serveur git n'a pas à fonctionner de la même manière qu'un client git ; des architectures de serveurs novatrices existent qui apportent des améliorations significatives en matière de mise à l'échelle. Les plateformes git peuvent fournir des RPC côté serveur complets comme Scion, peut-être même de manière standardisée entre les forges, que le client git peut apprendre à interroger. Le protocole de négociation n'a pas non plus à ressembler exactement à ce qu'il est aujourd'hui, et les diverses fonctionnalités sparse et shallow de git peuvent être rendues compatibles entre elles.
Enfin, nous tenons à reconnaître que la communauté git a consacré près de deux décennies à faire évoluer la plateforme pour des millions de développeurs. Notre contribution est bien plus restreinte : partager notre vision précoce de la manière dont le développement logiciel agentique interagit avec ces systèmes, afin de pouvoir nous associer à GitHub, GitLab et la communauté OSS pour répondre aux besoins changeants des développeurs. Nous sommes tous dans le même bateau alors que le cycle de vie du développement logiciel croît de façon exponentielle avec l'IA.
Notes de bas de page
01Stocker les fichiers modifiés par rapport au premier parent d'une fusion est un choix stylistique ; en pratique, nous avons constaté que les gens ne se soucient de l'historique ou du blame que pour les commits sur la ligne principale dans le développement trunk-based au sein d'un monorepo.
02Plus précisément, le composant serveur de Sapling, Mononoke. Il a été pionnier de nombreuses techniques que nous utilisons dans Scion, en particulier le Bonsai data model.
Auteurs & Remerciements
Remerciements
Écrit par Nick G. et l'équipe de gestion de source : S.G., R.K., Dan C., Garrett H., Ben L., Colin M., Joe P. Nous sommes reconnaissants à Vilas J. et Sergiu D. d'avoir soutenu l'équipe de gestion de source dans cette aventure ambitieuse, et à Amir O. pour ses premières contributions à Antique.