Was ist die Quellcodeverwaltung der nächsten Generation für KI-Teams?

Traditionelle Git-Workflows wurden primär für menschliche Entwickler(innen) konzipiert. Sie funktionieren gut, wenn Personen Repositorys klonen, Branches erstellen, Änderungen committen und die parallele Arbeit zusammenführen. Wenn Teams vermehrt auf Coding-Agents setzen, kann derselbe Workflow unnötige Repository-Transfers, Backend-Engpässe und Unsicherheit darüber erzeugen, welcher Agent welche Änderungen vorgenommen hat. Die SCM der nächsten Generation soll den Quellcode für Menschen und Agents zugänglich machen, ohne die Git-basierten Arbeitsabläufe, die Nachvollziehbarkeit und die Kontrollmechanismen zu beeinträchtigen, auf die sich Entwicklungsteams bereits verlassen. Die Quellcodeverwaltung der nächsten Generation ist eine Weiterentwicklung der traditionellen Quellcodeverwaltung für die KI-gestützte Entwicklung von Software in großem Umfang. Sie kombiniert die Kernfunktionen der SCM – Versionskontrolle, Branching, Code Review, Zusammenarbeit und Zugriffskontrolle – mit einer Infrastruktur, die für die Unterstützung vieler gleichzeitiger Softwareaufgaben ausgelegt ist. Der entscheidende Unterschied liegt nicht darin, ob Teams Git nutzen. Git bleibt eine wichtige Kompatibilitätsebene und ein zentrales Zusammenarbeitsmodell. Der Unterschied liegt darin, wie Agents und Entwickler(innen) auf Repository-Daten zugreifen, Aufgaben ausführen, gleichzeitige Änderungen verwalten und wie diese Arbeit gesteuert wird, damit die Teams Software bereitstellen können, der sie vertrauen. Eine SCM-Plattform der nächsten Generation könnte Folgendes bieten:

• Serverseitiger Zugriff auf die für eine Aufgabe benötigten spezifischen Repository-Daten, anstatt dass jeder Agent ein gesamtes Repository klonen muss. * Eine eher auf maschinelle Parallelverarbeitung als auf primär von Menschen gesteuerte Aktivitäten ausgelegte Backend-Infrastruktur. * Aufgabenspezifischer Zugriff und Isolation, damit Agents parallel arbeiten können, ohne unnötigerweise denselben Arbeitskontext teilen zu müssen. * Bessere Transparenz hinsichtlich Änderungen, Berechtigungen und Aktionen von menschlichen und KI-gestützten Mitwirkenden. * Integration in Code-Review-, CI/CD-, Sicherheits-, Governance- und Bereitstellungs-Workflows.

Die nächste Generation von SCM muss mehr leisten als nur Code zu speichern und Änderungen abzugleichen. Sie muss Teams dabei helfen, die Herausforderungen in Bezug auf Umfang, Koordination und Kontrolle zu bewältigen, die durch die Softwareentwicklung in Maschinengeschwindigkeit entstehen.

Gleichzeitiger Zugriff

Die SCM muss Repository-Daten effizient abrufen und bereitstellen, da viele Agents gleichzeitig Code abrufen, Branches erstellen, Merge Requests öffnen und Prüfungen auslösen. Durch die Zusammenfassung wiederholter Anfragen und die Optimierung des Datentransfers lässt sich die unnötige Last bei zunehmender Aktivität reduzieren.

Richtliniengesteuerte Validierung

Die generierten Änderungen sollten auf der Grundlage von Risikosignalen, erforderlichen Prüfungen, Approvalregeln und Unternehmensrichtlinien vorangetrieben werden. Indem diese Signale, Prüfungen und Regeln an die Standards angepasst werden, die Teams bereits für von Menschen vorgenommene Änderungen anwenden, können sie die bestehende Validierung auf die Arbeit von Agents ausweiten, anstatt ein separates System zu entwickeln. Die Validierung muss mit dem Volumen der generierten Ergebnisse skalieren, anstatt sich auf eine manuelle Überprüfung jeder einzelnen Aktion zu verlassen.

Lebenszykluskontext

Agents benötigen einen vernetzten, aktuellen und berechtigungsbasierten Kontext aus dem gesamten Softwarelebenszyklus. Dieser Kontext kann Workitems, Code-Eigentümer(innen), Abhängigkeiten, Pipelines, Umgebungen, erkannte Sicherheitsrisiken, Bereitstellungen, Produktionssignale und anwendbare Richtlinien umfassen.

Parallele Koordination

Agents benötigen abgeschlossene Workspaces und Informationen über zugehörige Aufgaben, damit sie Aufgaben parallel bearbeiten können, ohne widersprüchliche Änderungen zu verursachen. Die SCM sollte Teams dabei helfen, Überlappungen und veraltete Annahmen zu erkennen, bevor Änderungen in den gemeinsamen Verlauf eingehen.

Geltungsbereich

Jeder Agent sollte mit einer eindeutigen Identität und Berechtigungen arbeiten, die seiner Aufgabe und seinem potenziellen Einfluss entsprechen. Der Zugriff sollte auf das für die jeweilige Aufgabe Notwendige beschränkt werden, wobei für sensible oder vertrauliche Projekte und Actions strengere Kontrollen gelten sollten.

Dauerhafte Herkunftsverfolgung

Teams benötigen Nachweise, die eine Änderung mit dem menschlichen Ziel, der delegierten Befugnis, der Tätigkeit des Agent, der Validierung und der endgültigen Genehmigung in Verbindung bringen. Die Herkunftsnachverfolgung sollte die Verantwortlichkeit wahren, ohne dass Teams unbegrenzt Transkripte oder private Modellbegründungen speichern müssen. Zusammengenommen erweitern diese Anforderungen die SCM von einer reinen Code-Aufzeichnung zu einer operativen Grundlage für die agentische Softwarebereitstellung.

Herkömmliche SCM-Workflows können ineffizient werden, wenn alle Agents die gleichen Repository-Zugriffsmuster wie Entwickler(innen) verwenden. Die Herausforderung besteht nicht darin, dass Git die Zusammenarbeit nicht unterstützen kann. Sie besteht vielmehr darin, dass Hunderte oder Tausende von gleichzeitig aktiven Agents eine ganz andere Workload erzeugen können als ein Team von menschlichen Mitwirkenden.

Das Klonen von Repositorys erzeugt eine unnötige Belastung.

Viele Git-Workflows beginnen mit dem Klonen eines Repositorys in eine lokale Umgebung. Das ist sinnvoll, wenn Entwickler(innen) eine Arbeitskopie eines Projekts benötigen. Es wird aber ineffizient, wenn ein Agent nur eine Datei prüfen, eine Frage beantworten oder eine eng begrenzte Änderung vornehmen muss. Wenn jeder Agent und jeder Wiederholungsversuch das Repository klont, um auf eine kleine Menge an Informationen zuzugreifen, verbraucht die wiederholte Übertragung Zeit, Netzwerkkapazität, Speicherplatz und Verarbeitungsressourcen. Diese wiederholte Arbeit wird manchmal als Klon-Overhead oder Klon-Belastung bezeichnet.

Backends, auf die nur Menschen zugreifen, können an Grenzen des gleichzeitigen Zugriffs stoßen.

Eine Entwicklungsplattform, die bei von Menschen gesteuerten Aktivitäten gut funktioniert, kann sich anders verhalten, wenn viele Agents gleichzeitig Aufgaben starten. Sehr viele Sitzungen können dann gleichzeitig Repository-Daten anfordern, Branches erstellen, Operationen ausführen und Änderungen übermitteln. Ohne eine für diese Workload ausgelegte Infrastruktur kann es zu langsameren Reaktionszeiten, unvorhersehbarer Verfügbarkeit und Engpässen kommen, die den Nutzen der parallelen Agent-Ausführung einschränken.

Gemeinsam genutzte Workspaces können die Kontrolle der Agent-Aktivitäten erschweren.

Agents benötigen klare Grenzen hinsichtlich der Arbeit, die sie ausführen dürfen. Wenn mehrere Agents Konten, Branches oder Arbeitskontexte gemeinsam nutzen, ist möglicherweise schwieriger, festzustellen, welcher Agent eine Änderung vorgenommen hat, erfolglose Experimente sauber zu verwerfen oder zu verhindern, dass eine Aufgabe eine andere beeinträchtigt. Teams benötigen daher Versionskontrolle-Workflows, die paralleles Experimentieren unterstützen und gleichzeitig Berechtigungen, Review-Prozesse und einen nachvollziehbare Änderungsverlauf gewährleisten.

Die SCM der nächsten Generation verändert die Infrastruktur rund um den Repository-Zugriff und die gleichzeitige Bearbeitung von Aufgaben, wobei die Konzepte, die Entwickler(innen) bereits kennen, erhalten bleiben.

Der serverseitige Zugriff reduziert unnötige Repository-Transfers.

Anstatt dass ein Agent für jede Aufgabe ein gesamtes Repository klonen muss, kann der SCM-Dienst einen strukturierten oder aufgabenspezifischen Zugriff auf die für diese Aufgabe benötigten Repository-Daten ermöglichen. Dieser Ansatz kann wiederholte Netzwerkübertragungen reduzieren und den Agents relevante Informationen direkter bereitstellen. Er ist besonders sinnvoll, wenn Agents große Repositorys untersuchen, an vielen Projekten gleichzeitig arbeiten oder Aufgaben häufig wiederholen müssen.

Git-Kompatibilität schützt bestehende Workflows.

Durch die Git-Kompatibilität können Teams weiterhin vertraute Repositorys, Protokolle, Branching-Modelle, Merge Requests und Entwicklungstools nutzen. Ein neu gestaltetes Backend erfordert nicht zwangsläufig, dass alle Entwickler(innen) oder jede Integration ein völlig neues Versionskontrollmodell einführt. Diese Unterscheidung ist wichtig für Unternehmensteams, die in Git-basierte Prozesse, Automatisierung, Compliance-Kontrollen und Entwicklerschulungen investiert haben. Ziel ist es, das zugrundeliegende System zu verbessern, ohne die Teams zu zwingen, Workflows aufzugeben, die die Softwarebereitstellung bereits unterstützen.

Gleichzeitiger Zugriff durch Agents unterstützt paralleles Arbeiten

Die SCM der nächsten Generation ist für sehr viele zeitgleiche Softwareaufgaben ausgelegt. Dies kann Teams dabei helfen, Agents über Repositorys und Projekte hinweg auszuführen, ohne jede Aufgabe als eine vom Menschen gesteuerte Klon-, Branch- und Checkout-Sequenz zu behandeln. Die Plattform muss weiterhin Konflikte, Berechtigungen und Review-Anforderungen verwalten. Die Skalierung des gleichzeitigen Zugriffs beseitigt nicht die Notwendigkeit technischer Kontrollmechanismen, sondern erhöht vielmehr die Bedeutung der konsequenten Anwendung dieser Kontrollmechanismen.

Aufgabenspezifischer Zugriff verbessert Isolation und Kontrolle

Agents sollten die minimale Sichtbarkeit und den minimalen Zugriff auf das Repository erhalten, die für die von ihnen ausgeführten Aufgaben erforderlich sind. Der aufgabenspezifische Zugriff kann eine unnötige Offenlegung verringern und Teams dabei helfen, unabhängige Experimente zu trennen. Die Isolation erleichtert es zudem die Arbeit von Agents zu überprüfen, zu verwerfen oder zu reproduzieren. Diese Kontrollen sollten mit geschützten Branches, Merge Requests, Approvalregeln, Audit Events und anderen etablierten SCM-Sicherheitsmechanismen verzahnt sein.

Parallel agierende Agents können Änderungen verursachen, die einzeln betrachtet gültig, aber in ihrer Gesamtheit widersprüchlich sind. Bei herkömmlichen Merge-Konflikten werden widersprüchliche Bearbeitungen identifiziert, jedoch nicht immer widersprüchliche Absichten, veraltete Annahmen oder Änderungen, die ähnliche Probleme auf inkompatible Weise lösen. Die SCM der nächsten Generation sollte den Agents simple, isolierte Bereiche für spekulatives Arbeiten und einen klaren Weg bieten, um fehlgeschlagene Versuche zu verwerfen oder validierte Ergebnisse in den gemeinsamen Verlauf aufzunehmen. Isolation trägt dazu bei, dass die Experimente eines Agent die Arbeit anderer Agents oder der Mitwirkenden nicht beeinträchtigen. Sie soll Teams auch dabei helfen, die Zusammenhänge zwischen gleichzeitig ausgeführten Aufgaben nachzuvollziehen. Ein Agent könnte beispielsweise die Authentifizierungslogik ändern, während ein anderer denselben Workflow optimiert und ein dritter einen abhängigen Dienst aktualisiert. Die Branches könnten auch dann sauber zusammengeführt werden, obwohl die zugrunde liegenden Ziele im Widerspruch zueinander stehen. Die absichtsorientierte Koordination kann die traditionellen Git-Operationen ergänzen, indem sie Teams dabei hilft, sich überschneidende Ziele, veraltete Kontexte und übergeordnete Konflikte zu identifizieren, bevor Änderungen zusammengeführt werden.

Governance muss greifen, bevor ein Agent eine Aktion ausführt, und nicht erst, nachdem eine Änderung bis zur Code Review gelangt ist. Ein Review durch Menschen bleibt wichtig, kann aber nicht auf jede einzelne Aktion eines Agent ausgeweitet werden, wenn Softwarearbeit kontinuierlich generiert wird. Ein praktisches Governance-Modell besteht aus zwei Ebenen:

Projektgenehmigung

Die Projektgenehmigung legt fest, ob ein Agent überhaupt in einem Projekt tätig werden darf. Dabei sollten die Vertraulichkeit des Projekts, die Zuständigkeiten, die Auswirkungen des Einsatzes sowie die Identität oder die Delegation, unter der der Agent handelt, berücksichtigt werden.

Richtlinie auf Aktionsebene

Die Richtlinie auf Aktionsebene definiert, was ein autorisierter Agent im Projekt tun darf. Actions mit geringem Risiko können automatisch ausgeführt werden, vertrauliche Actions hingegen können eine Genehmigung erfordern und verbotene Aktionen werden blockiert. Beispiel:

• Einem Agent erlauben, zulässige Dateien zu lesen, einen Feature-Branch zu erstellen und genehmigte Tests auszuführen. * Approval anfordern, bevor vertrauliche Komponenten geändert, ein risikoreicher Merge Request geöffnet oder eine Produktionsbereitstellung ausgelöst werden. * Den Zugriff auf eingeschränkte Projekte sowie Versuche, geschützte Richtlinien zu umgehen, oder destruktive Aktionen außerhalb des Zuständigkeitsbereichs des Agent verweigern. Die getroffenen Entscheidungen sollten mit den Änderungen und Workflows, die sie regeln, in Verbindung stehen, damit Teams nachvollziehen können, was passiert ist, warum es zulässig war und welche Artefakte betroffen waren.

Git bietet eine dauerhafte Aufzeichnung von Codeänderungen, einschließlich Commit, Autor(in) bzw. Committer, Zeitstempel, übergeordnete Beziehungen und Nachricht. Delegierte Maschinenarbeit erfordert eine umfassendere Verantwortungskette, da die Person, die eine Änderung angefordert hat, der Agent, der sie ausgeführt hat, und die Person, die sie genehmigt hat, unterschiedlich sein können. Nützliche agentische Provenienz kann Folgendes verbinden:

• Das menschliche Ziel oder das Workitem, das die Aufgabe ausgelöst hat. * Die Identität und die dem Agent übertragenen Befugnisse. * Die Agent-Sitzung, der Kontext und die verwendeten Tools. * Die daraus resultierende Codeänderung und die betroffenen Repositorys. * Tests, Richtlinienprüfungen und andere Validierungsnachweise. * Entscheidungen über Review, Approval und Zusammenführungen durch Menschen. Ziel ist es nicht, jeden Prompt oder jede private Modelllogikspur zu speichern. Ziel ist es, die Nachweise zu speichern, mit deren Hilfe Teams nachvollziehen können, was sich geändert hat, warum es sich geändert hat, welche Stelle dies genehmigt hat, wie es validiert wurde und wer das Ergebnis genehmigt hat.

Die Vorteile der SCM der nächsten Generation ergeben sich aus der Anpassung der Infrastruktur zur Quellcodeverwaltung an die tatsächliche Funktionsweise der KI-gestützten Entwicklung.

Geringerer Transfer- und Kontextaufwand

Wenn Agents die für eine Aufgabe benötigten Repository-Daten abrufen können, ohne wiederholt ganze Repositorys klonen zu müssen, können Teams unnötigen Netzwerkverkehr sowie Verarbeitungs- und Infrastrukturkosten reduzieren. Agents können mehr von ihrem verfügbaren Kontext für die Lösung der Aufgabe verwenden, anstatt den Repository-Zustand wiederherzustellen.

Schnellere parallele Ausführung

Eine für gleichzeitige Workloads ausgelegte Versionskontrolle-Infrastruktur kann vielen Agents das gleichzeitige Arbeiten ermöglichen, ohne ein für menschliche Arbeitsgeschwindigkeit ausgelegtes Backend zu überlasten. Dies kann die Reaktionsfähigkeit großer Repositorys, Monorepos und von Unternehmen, die viele automatisierte Aufgaben ausführen, verbessern.

Sicherere Experimente

Agents benötigen Freiraum zum Erkunden, Teams hingegen eine zuverlässige Möglichkeit, erfolglose Versuche zu überprüfen und zu verwerfen. Aufgabenspezifischer Zugriff, isolierte Workspaces, übersichtlicher Änderungsverlauf und Merge-Request-Reviews können Teams dabei helfen, ein Gleichgewicht zwischen Experimentieren und Kontrolle zu finden.

Bessere Kennzeichnung der Beiträge von Menschen und KI

Da Agents immer aktiver mitwirken, müssen Teams nachvollziehen können, was geändert wurde, welche Aufgabe die Änderung verursacht hat, welche Berechtigungen verwendet wurden und wo ein Review durch Menschen erforderlich ist. Die SCM der nächsten Generation sollte es ermöglichen, diese Fragen leichter zu beantworten, anstatt dem Entwicklungsprozess eine weitere undurchsichtige Ebene hinzuzufügen.

Eine stärkere Grundlage für eine gesteuerte Leistungserbringung

Versionskontrolle ist mit Code Review, Tests, Sicherheitsprüfungen, Bereitstellung und Compliance verknüpft. Eine SCM-Plattform der nächsten Generation sollte sich in diese Workflows integrieren, damit Teams die Entwicklungsgeschwindigkeit erhöhen können, ohne die Aktivitäten von Agents von den Kontrollmechanismen zu trennen, die für die Bereitstellung vertrauenswürdiger Software verwendet werden.

Die agentische Softwareentwicklung umfasst mehr als nur die Generierung von Code. Agents können Probleme interpretieren, Repositorys überprüfen, Änderungen vornehmen, auf Code Reviews reagieren, Tests ausführen und bei der Behebung von Pipeline-Fehlern helfen. Die Quellcodeverwaltung ist die Ausführungsebene, die diese Änderungen speichert, versioniert, überprüft und koordiniert. Sie muss mit den anderen Teilen des Softwarelebenszyklus kompatibel sein:

• Daten zu Planung und Problemen liefern die Aufgabendefinition und die Akzeptanzkriterien. * Die Versionskontrolle stellt den Repository-Status, Branches, Commits und den Änderungsverlauf bereit. * Der Code Review liefert menschliches und automatisiertes Feedback, bevor Änderungen zusammengeführt werden. * CI/CD validiert, verpackt und liefert die Änderungen aus. * Sicherheits- und Compliance-Mechanismen entscheiden darüber, ob die Änderung durchgeführt werden kann. * Bereitstellungs- und Produktionssignale liefern Feedback für die nächste Aufgabe. Aus diesem Grund sollte die SCM der nächsten Generation nicht als isolierte Repository-Funktion beurteilt werden. Der Nutzen hängt davon ab, wie gut die Quellcodeverwaltungsebene mit dem Kontext, der Automatisierung und der Governance rund um sie herum verzahnt ist. Die intelligente Orchestrierungsplattform von GitLab ist darauf ausgelegt, die Arbeit über diese Lebenszyklusphasen hinweg zu koordinieren.

Teams, die sich mit der SCM der nächsten Generation beschäftigen, sollten über die Repository-Speicherung und die grundlegende Git-Kompatibilität hinausblicken. Viel wichtiger ist, ob die Plattform den Umfang, die Kontrollmechanismen und die Workflows unterstützt, die dein Unternehmen benötigt.

Repository- und Protokollkompatibilität

Vergewissere dich, dass bestehende Repositorys, Git-Clients, Automatisierungen, Integrationen und Entwicklungsworkflows weiterhin funktionieren. Informiere dich, welche Schnittstellen heute kompatibel sind und welche Funktionen sich noch in der Vorschauphase befinden.

Gleichzeitigkeit und Leistung

Teste realistische Workloads, darunter große Repositorys, Monorepos, Multi-Repository-Aufgaben, gleichzeitig stattfindende Sitzungen von Agents und wiederholte Wiederholungsversuche. Erfasse Reaktionszeit, Netzwerkauslastung, Ausfallraten und die Zeit, die zur Erledigung repräsentativer Aufgaben benötigt wird.

Zugriffskontrolle und Isolation

Überprüfe, ob jeder Agent nur die für seine Aufgabe erforderliche Transparenz bzw. Berechtigungen erhält. Prüfe, wie die Plattform Tätigkeiten isoliert, Zugangsdaten verwaltet, Aktionen protokolliert und verhindert, dass sich Aufgaben gegenseitig beeinträchtigen.

Review und Governance

Prüfe, wie von Agents erstellte Änderungen zum Code Review gelangen, wie Genehmigungsrichtlinien durchgesetzt werden und wie Teams die daraus resultierenden Aktivitäten prüfen können. Eine schnellere Code Generation sollte die für Produktionssoftware erforderlichen Kontrollmechanismen nicht umgehen.

Lebenszyklusintegration

Beurteile, wie die SCM-Plattform mit Ticketverfolgung, Code Review, CI/CD, Sicherheitstests, Bereitstellung, Beobachtbarkeit und Produktionsfeedback verknüpft ist. Der größte Nutzen ergibt sich aus der Reduzierung von Übergaben über den gesamten Lebenszyklus hinweg, anstatt Repository-Operationen isoliert zu beschleunigen.

Verfügbarkeit und Einführung

Betrachte allgemein verfügbare Funktionen losgelöst von Funktionen der privaten Betaversion oder des frühen Zugriffs. Dokumentiere den geplanten Einführungspfad, die Migrationsanforderungen, das Supportmodell und den Ausweichprozess, bevor du die Vorschauinfrastruktur für kritische Workflows nutzt.

Führungskräfte in der Entwicklung können im Rahmen der Vorbereitungen auf die SCM der nächsten Generation als ersten Schritt ermitteln, wo die Aktivitäten durch Agents am ehesten Druck erzeugen werden.

Zugriff und Infrastruktur

Vergleiche Klone vollständiger Repositorys mit dem gezielten Abrufen. Behalte Repository-Latenz, Warteschlangenlänge, Netzwerkauslastung, Speicher- und Rechenbedarf bei zunehmender Aktivität durch Agents im Blick.

Generierung und Validierung

Vergleiche die Rate der generierten Änderungen mit den verfügbaren Test-, Prüf- und Genehmigungskapazitäten. Achte auf zunehmende Verzögerungen zwischen der Codeerstellung und der vertrauenswürdigen Veröffentlichung.

Befugnis und Exposition

Bilde ab, wo Agents agieren können und worauf sie einwirken können. Identifiziere Zugriffsrechte, die über die Erfordernisse der jeweiligen Aufgabe hinausgehen, insbesondere im Hinblick auf vertraulichen Code, Produktionsumgebungen und Sicherheitsmaßnahmen.

Verantwortlichkeit

Prüfe, ob die Teams eine Änderung mit ihrem Ziel, der delegierten Befugnis, der Maschinenaktivität, der Validierung und dem endgültigen Approval verknüpfen können. Fehlender Kontext, unklares Eigentum und unvollständige Aufzeichnungen erschweren das Vertrauen in von Agents initiierte Änderungen. Diese Signale zeigen auf, wo bestehende Systeme und Kontrollen zuerst weiterentwickelt werden müssen und helfen Teams, Investitionen zu priorisieren, bevor die Aktivität durch Agents einen größeren Umfang erreicht.

Die SCM der nächsten Generation von GitLab ist eine Git-Engine, die für die gleichzeitige Verarbeitung durch Agents neu entwickelt wurde. Dieser Ansatz behält das Git-Protokoll aus Gründen der Abwärtskompatibilität bei, verwendet aber ein neu gestaltetes Backend und Schnittstellen, die speziell für Agents entwickelt wurden. Herangehensweise von GitLab:

• Unnötiges Klonen des gesamten Repository durch gezielteren serverseitigen Zugriff ersetzen. * Viele Agents unterstützen, die gleichzeitig in verschiedenen Repositorys arbeiten. * Jedem Agent die für seine Aufgabe erforderliche minimale Repository-Transparenz gewähren. * Kompatibilität und Nachvollziehbarkeit von Git erhalten und gleichzeitig die zugrunde liegende Ausführungsebene verbessern. * Agents ermöglichen, sicher zu experimentieren, ohne Entwickler(innen) aus ihren bestehenden Workflows herauszureißen.

Die Quellcodeverwaltung entwickelt sich zur Infrastruktur für menschliche und KI-gestützte Mitwirkende. Teams, die auf Agent-weite Parallelverarbeitung, aufgabenspezifischen Zugriff und gesteuerte Änderungsworkflows setzen, können die KI-gestützte Entwicklung nutzen, ohne Geschwindigkeit und Kontrolle als gegensätzliche Ziele zu betrachten.

Erfahre mehr über Quellcodeverwaltung oder beantrage frühzeitigen Zugriff auf die nächste Generation der SCM-Lösung von GitLab.