Git ist über zwanzig Jahre alt, wurde in wenigen Tagen aus einem Lizenzstreit heraus geboren und galt lange als Werkzeug, das Entwickler unter sich ausmachen. Für alle anderen im Unternehmen war es bestenfalls ein Wort aus der IT-Abteilung.
Das hat sich geändert — nicht weil Git anders geworden wäre, sondern weil KI-Agenten wie Claude Code und Codex inzwischen selbstständig Code schreiben. Damit wird aus einem Kollaborationswerkzeug etwas anderes: die Rückfahrkarte. Dieser Artikel erklärt, was Git ist, warum es ausgerechnet jetzt für Entscheider relevant wird und was du davon in deinem Unternehmen wissen musst.
Ein Werkzeug, das aus einem Streit entstand
Die Entstehung ist ungewöhnlich genug, um sie kurz zu erzählen. Der Linux-Kernel wurde ab 2002 mit BitKeeper verwaltet, einem kommerziellen System, das kostenlos genutzt werden durfte. Am 5. April 2005 kündigte der Hersteller BitMover an, diese kostenlose Version einzustellen — als Grund nannte er, dass ein Entwickler das Protokoll nachgebaut hatte.
Einen Tag später schrieb Linus Torvalds auf der Kernel-Mailingliste unter dem Betreff „Kernel SCM saga..“, das Team sehe sich nach Alternativen um. Bemerkenswert daran: Git kommt in dieser Mail nicht vor — Torvalds verwies damals auf ein anderes Projekt. Tatsächlich hatte er da bereits am 3. April begonnen, selbst etwas zu schreiben. Am 7. April 2005 verwaltete Git seinen eigenen Quellcode; der allererste Commit trägt bis heute die Nachricht „Initial revision of ‘git’, the information manager from hell“.
Vier Tage von der Idee zum funktionierenden System. Die Wartung gab Torvalds übrigens schon im Juli 2005 an Junio Hamano ab, der im Dezember die Version 1.0 veröffentlichte — Git ist also seit zwei Jahrzehnten nicht mehr Torvalds' Projekt, auch wenn sein Name daran hängen bleibt.
Warum das Thema ausgerechnet jetzt hochkommt
Weil sich geändert hat, wer den Code schreibt. Der State of AI-assisted Software Development-Report von Google Cloud und DORA (Erhebung Juni bis Juli 2025, 4.867 befragte Fachkräfte rund um die Softwareentwicklung, 90 Prozent davon nutzen KI bei der Arbeit) hat gefragt, wie lange am jeweils letzten Arbeitstag mit KI gearbeitet wurde. Der Median unter den KI-Nutzern: zwei Stunden — also rund ein Viertel eines Achtstundentages.
Interessanter ist die zweite Zahl. Gefragt nach dem Vertrauen in die Qualität KI-generierter Ergebnisse, äußerten 70 Prozent zumindest ein gewisses Vertrauen — aber nur 24 Prozent ein hohes. 30 Prozent trauen den Ergebnissen wenig oder gar nicht. DORA wertet das ausdrücklich nicht als Warnsignal, sondern als „gesunde Skepsis“ und Zeichen reifer Nutzung. Die Haltung, die dahintersteht, nennt der Report trust but verify: vertrauen, aber überprüfen.
Und damit ist die eigentliche Frage gestellt: Womit überprüft man das? Man kann nicht jede Zeile lesen, die ein Agent in zwei Stunden produziert. Man braucht ein Werkzeug, das genau zeigt, was sich verändert hat, und das jeden Stand zurückholen kann. Dieses Werkzeug ist Git. Es wurde nicht dafür gebaut — aber es ist zufällig genau das, was der Moment verlangt.
Was Git eigentlich ist
Stell dir vor, dein Unternehmen hätte eine Fassung jedes Dokuments, die sich lückenlos zurückspulen lässt. Nicht „Angebot_final_v3_NEU_wirklich_final.docx“, sondern eine einzige Datei mit vollständiger Historie: Wer hat wann welche Zeile geändert, warum, und was war der Stand davor. Genau das leistet Git — nur für Programmcode.
Vier Begriffe reichen fürs Verständnis:
- Repository (kurz Repo): der Projektordner samt kompletter Historie. Er liegt vollständig auf jedem Rechner, der mitarbeitet.
- Commit: ein gespeicherter Stand mit Notiz, was geändert wurde. Der Speicherpunkt im Spiel — du kannst jederzeit dorthin zurück.
- Branch (Zweig): eine Abzweigung, auf der du etwas ausprobierst, ohne den funktionierenden Stand anzufassen.
- Merge: das Zusammenführen eines Zweigs zurück in den Hauptstand, wenn er sich bewährt hat.
Der entscheidende Punkt: Git speichert nicht Dateien, sondern Veränderungen. Deshalb kann es jederzeit genau zeigen, was sich zwischen zwei Ständen unterscheidet — zeilengenau. Dieses „Was hat sich geändert?“ heißt Diff, und es ist der Kern dessen, warum Git im KI-Zeitalter plötzlich für alle relevant wird.
Warum das mit KI eine ganz neue Bedeutung bekommt
Solange Menschen Code geschrieben haben, war Git vor allem ein Werkzeug für Zusammenarbeit: mehrere Entwickler, ein Projekt, niemand überschreibt den anderen. Diese Rolle hat es weiterhin. Aber seit KI-Agenten selbstständig Code schreiben, kommt eine zweite dazu, die viel wichtiger ist: Git ist das Sicherheitsnetz.
Der Unterschied ist grundsätzlich. Ein Mensch schreibt zwanzig Zeilen und weiß, was er getan hat. Ein Agent wie Claude Code oder Codex bearbeitet in einem Durchgang fünfzehn Dateien, benennt eine Funktion um, passt die Aufrufe an, korrigiert einen Test. Das ist genau der Grund, warum man solche Werkzeuge einsetzt — und genau der Grund, warum du eine Rückfahrkarte brauchst.
Drei Dinge macht Git möglich, die ohne Versionskontrolle schlicht nicht gehen:
- Prüfen statt vertrauen. Vor dem Übernehmen zeigt dir der Diff exakt, was der Agent angefasst hat. Nicht „die KI sagt, sie hat X geändert“, sondern die tatsächlichen Zeilen. Wer Agenten ohne diesen Blick laufen lässt, übernimmt Änderungen blind.
- Zurück in Sekunden. Läuft ein Versuch aus dem Ruder, holst du den letzten funktionierenden Stand mit einem Befehl zurück. Ohne Git ist die Alternative: manuell zurückbauen und hoffen, nichts übersehen zu haben.
- Schadensbegrenzung. Jeder Versuch bekommt einen eigenen Zweig. Geht er schief, wirfst du den Zweig weg — der Hauptstand war nie in Gefahr.
Diese Logik gilt übrigens nicht nur für Code. Wir haben an anderer Stelle beschrieben, woran KI-Projekte scheitern, und ein wiederkehrendes Muster ist: Es fehlt der Weg zurück. Wer nicht gefahrlos scheitern kann, probiert nichts aus.
So arbeiten KI-Agenten mit Git
Die gängigen Werkzeuge setzen Git nicht nur voraus — sie bauen ihre Arbeitsweise darauf auf.
Claude Code
Claude Code arbeitet direkt in deinem Repository. Interessant ist, wie eng die Verzahnung ist: Es gibt gar kein eigenes Git-Werkzeug — Git-Befehle laufen über die normale Kommandozeile, werden dort aber gesondert behandelt. Lesende Git-Befehle sind von der Berechtigungsabfrage ausgenommen, weil sie nichts verändern können. Der Blick in die Historie kostet also keine Bestätigung, das Schreiben schon.
Commits und Pull Requests löst man schlicht per Zuruf aus — „commit das mit einer aussagekräftigen Nachricht“ genügt, einen eingebauten Befehl dafür gibt es nicht. Legt Claude Code einen Pull Request an, verknüpft es die Arbeitssitzung damit; über die PR-Nummer lässt sich später genau die Unterhaltung wiederfinden, aus der die Änderung entstanden ist. Das ist in der Praxis wertvoller, als es klingt: Du siehst nicht nur, was geändert wurde, sondern kommst an die Begründung heran.
OpenAI Codex
Bei Codex lohnt eine Vorbemerkung, weil der Name zweimal vergeben wurde: 2021 hieß so ein Sprachmodell, das 2023 abgekündigt wurde. Der heutige Codex ist ein davon unabhängiger Coding-Agent, dessen Kommandozeilen-Version im April 2025 erschien, gefolgt von einer Cloud-Variante im Mai.
Heute ist Codex weniger ein Werkzeug als ein Bündel von Oberflächen — Desktop-App, Web, Kommandozeile, Editor-Erweiterung und Cloud. Für unser Thema am interessantesten: die Anbindung an Pull Requests. Codex kann Änderungsvorschläge auf GitHub und GitLab kommentieren und prüfen. Damit wird der Agent nicht nur zum Autor, sondern auch zum Prüfer — und beides passiert an der Stelle, an der Git ohnehin die Änderungen verwaltet.
Der gemeinsame Nenner
Beide Ansätze laufen auf dasselbe hinaus: Der Agent schlägt vor, der Mensch entscheidet, Git protokolliert. Ohne Repository fehlt beiden die Grundlage. Deshalb ist die ehrliche Antwort auf „Brauchen wir Git?“ heute nicht mehr „wenn ihr Software entwickelt“, sondern „sobald ihr KI an euren Code lasst“.
Was das für dein Unternehmen praktisch heißt
Du musst Git nicht selbst beherrschen, um von dieser Logik zu profitieren. Aber du solltest wissen, was du von deinem Dienstleister oder deinem Team erwarten kannst. Vier Fragen, die du stellen kannst:
- Liegt unser Code in einem Repository — und haben wir Zugriff darauf? Das ist die wichtigste Frage überhaupt. Wenn der Code nur auf dem Rechner einer Agentur liegt, gehört er faktisch nicht dir. Ein Repository bei GitHub oder GitLab, auf das dein Unternehmen Zugriff hat, ist die Grundabsicherung.
- Wird jede Änderung nachvollziehbar dokumentiert? Aussagekräftige Commits sind kein Selbstzweck: Sie sind die Antwort auf „Warum funktioniert das seit dem 14. nicht mehr?“.
- Gibt es einen Review-Schritt, bevor etwas live geht? Besonders bei KI-generiertem Code. Vier Augen auf den Diff, bevor es auf den Produktivserver geht.
- Wie schnell kommen wir zurück? Wenn ein Deployment Probleme macht — wie lange dauert der Rückweg? Mit Git sind das Minuten. Ohne Git ist es ein Projekt.
Wenn du eigene Software entwickeln lässt, gehört das in den Vertrag. Wir haben ausführlich beschrieben, ab wann eigene Software Sinn ergibt — der Zugriff auf das Repository ist dabei kein technisches Detail, sondern die Eigentumsfrage.
Der Einstieg, wenn du es selbst probieren willst
Falls du selbst mit KI-Werkzeugen baust — und das tun inzwischen erstaunlich viele Nicht-Entwickler — reicht ein sehr kleines Repertoire:
- Ein Repository anlegen und den ersten funktionierenden Stand sichern. Ab hier gibt es immer einen Weg zurück.
- Nach jedem gelungenen Schritt committen. Lieber zehn kleine Speicherpunkte als einer nach zwei Tagen. Kleine Commits sind leichter zu prüfen und gezielter zurückzunehmen.
- Für Experimente einen Zweig anlegen. Klappt es, wird zusammengeführt. Klappt es nicht, wird der Zweig gelöscht — ohne Spuren.
- Vor dem Übernehmen den Diff lesen. Auch wenn du nicht jede Zeile verstehst: Du siehst, wie viel angefasst wurde. Wenn eine kleine Anpassung plötzlich zwanzig Dateien betrifft, ist das ein Grund nachzufragen.
Das Gute daran: Die KI-Werkzeuge selbst erklären dir Git. Du kannst Claude Code schlicht fragen, was der letzte Commit geändert hat oder wie du zum Stand von gestern zurückkommst — und es führt die Befehle aus. Die Einstiegshürde, die Git jahrzehntelang hatte, ist damit deutlich kleiner geworden.
Häufige Fragen zu Git
Brauche ich Git, wenn wir gar nicht selbst programmieren?
Selbst dann lohnt die Frage, ob euer Dienstleister sauber damit arbeitet und ihr Zugriff auf das Repository habt. Das ist eure Absicherung: Bei einem Anbieterwechsel, bei einem Streit oder wenn jemand ausfällt, ist das Repository der einzige vollständige Bestand dessen, wofür ihr bezahlt habt.
Ist GitHub dasselbe wie Git?
Nein. Git ist die Technik, die auf jedem Rechner läuft. GitHub, GitLab und Bitbucket sind Plattformen, die Repositories im Netz bereitstellen und Zusammenarbeit ergänzen — Rechteverwaltung, Reviews, Automatisierung. Man kann Git ohne solche Plattform nutzen; im Team nimmt man in der Regel eine.
Was kostet das?
Git selbst ist freie Software und kostet nichts. Bei den Plattformen sind private Repositories in kleinen Teams meist kostenlos; bezahlt wird für größere Teams und Zusatzfunktionen. Für ein mittelständisches Unternehmen ist das selten der Kostentreiber — die Frage ist eher, wo die Daten liegen.
Können wir Git auch für Nicht-Code nutzen, etwa Verträge oder Dokumentation?
Technisch ja, und für Textdateien funktioniert es hervorragend — Markdown-Dokumentation liegt in vielen Unternehmen im Repository. Bei Word- und Excel-Dateien bringt es dagegen wenig, weil Git deren Binärformat nicht zeilenweise vergleichen kann. Dafür sind Dokumentenmanagement-Systeme die bessere Wahl.
Fazit: Die Rückfahrkarte ist die eigentliche Innovation
Git ist über zwanzig Jahre alt und wirkt auf den ersten Blick wie ein Entwicklerthema. Tatsächlich ist es gerade zur Voraussetzung dafür geworden, KI überhaupt verantwortbar an Code zu lassen. Denn was Agenten produktiv macht — Geschwindigkeit und Reichweite — macht sie ohne Sicherheitsnetz auch gefährlich.
Die eigentliche Erkenntnis ist keine technische, sondern eine über Arbeitsweise: Wer jederzeit zurückkann, kann mehr ausprobieren. Teams mit sauberer Versionskontrolle setzen KI-Werkzeuge mutiger ein, weil ein Fehlversuch nichts kostet außer der Zeit. Teams ohne sie tasten sich vorsichtig heran und holen einen Bruchteil des Nutzens.
Wenn du wissen willst, wie ihr KI in der Entwicklung sinnvoll und abgesichert einsetzt — von der Werkzeugwahl bis zum Review-Prozess — schauen wir uns das in einer kostenlosen Prozessanalyse gemeinsam an.