Schematische Diff-Ansicht: links die alte Dateiversion, rechts die neue; dazwischen ein Ausschnitt mit rot markierten Minus-Zeilen für Löschungen, grün markierten Plus-Zeilen für Hinzufügungen und grauen Kontextzeilen darüber und darunter.

Code-Diff

Ein Code-Diff ist eine Gegenüberstellung, die zeigt, welche Zeilen einer Datei sich zwischen zwei Ständen geändert haben. Entwicklerinnen und Entwickler prüfen damit Änderungen, und KI-Assistenten schlagen ihre Vorschläge oft genau in dieser Form vor.

Programme bestehen aus Textdateien, in denen Anweisungen Zeile für Zeile stehen. Wenn jemand daran arbeitet, ändert sich meist nur ein winziger Teil davon. Ein Code-Diff ist eine Darstellung, die genau diesen Unterschied zwischen zwei Ständen einer Datei sichtbar macht. Er zeigt, welche Zeilen entfernt und welche neu hinzugekommen sind, und lässt alles Unveränderte weitgehend weg. Auf dem Bildschirm sind entfernte Zeilen üblicherweise rot mit einem Minuszeichen markiert, neue grün mit einem Pluszeichen. Der Name kommt vom englischen Wort difference, also Unterschied.

Warum niemand tausend Zeilen doppelt liest

Ein größeres Softwareprojekt umfasst schnell hunderttausende Zeilen. Niemand kann bei jeder Änderung die ganze Datei erneut durchlesen. Der Diff reduziert die Prüfung auf das, was sich tatsächlich bewegt hat. Aus einer Datei mit 2.000 Zeilen wird so eine Ansicht mit vielleicht zwölf betroffenen Zeilen.

Darauf baut ein fester Arbeitsablauf auf: das Code-Review. Bevor eine Änderung in das gemeinsame Projekt aufgenommen wird, schaut mindestens eine zweite Person darauf. Diese Person liest fast immer den Diff, nicht den vollständigen Code. Fehler, Sicherheitslücken und unabsichtliche Löschungen fallen so auf, bevor sie bei Nutzern landen.

Der Diff ist außerdem ein Protokoll. Zu jeder Änderung in der Projektgeschichte lässt sich später nachvollziehen, wer wann welche Zeile angefasst hat. Wenn eine Software plötzlich nicht mehr funktioniert, sucht man gezielt in den letzten Diffs. Oft findet man den Fehler in wenigen Minuten statt in Stunden.

Wie der Vergleich Zeile für Zeile entsteht

Ein Diff-Programm bekommt zwei Textversionen und sucht die längste gemeinsame Folge von Zeilen. Alles, was in dieser gemeinsamen Folge liegt, gilt als unverändert. Was nur in der alten Version steht, wird als Löschung markiert. Was nur in der neuen Version vorkommt, gilt als Hinzufügung. Eine geänderte Zeile ist technisch also kein eigener Fall, sondern eine Löschung plus eine Hinzufügung.

Damit die Ansicht lesbar bleibt, zeigt das übliche Format zusätzlich drei unveränderte Zeilen ober- und unterhalb jeder Änderung. Diese Umgebung nennt man Kontext. Ein solcher zusammenhängender Abschnitt heißt Hunk. Eine Kopfzeile darin gibt an, ab welcher Zeilennummer der Abschnitt in beiden Versionen beginnt.

Ein häufiger Irrtum: Ein Diff beschreibt keine Bedeutung, sondern nur Text. Wenn jemand eine Funktion an eine andere Stelle der Datei verschiebt, sieht das Werkzeug eine große Löschung und eine große Hinzufügung. Inhaltlich hat sich nichts geändert, der Diff wirkt trotzdem dramatisch. Moderne Werkzeuge mildern das ab, indem sie Verschiebungen erkennen oder Unterschiede innerhalb einer Zeile farbig hervorheben.

Diffs in KI-Assistenten und in Tech-News

Wer Software mit anderen zusammen entwickelt, nutzt meist die Versionsverwaltung Git, also ein System, das alle Zwischenstände eines Projekts speichert. Plattformen wie GitHub oder GitLab zeigen dort jeden Änderungsvorschlag als Diff mit grünen und roten Zeilen an. Genau diese Ansicht sehen auch Außenstehende, wenn in einer Meldung von einem eingereichten Patch die Rede ist.

In der KI-Welt ist der Diff zum Standardformat für Programmierassistenten geworden. Werkzeuge wie GitHub Copilot oder Claude Code geben ihre Vorschläge nicht als komplette neue Datei aus, sondern als Änderungsblock. Das spart Rechenaufwand und macht den Vorschlag prüfbar. Der Mensch sieht auf einen Blick, was das Modell anfassen will, und bestätigt oder verwirft es.

Auch die Bewertung solcher Systeme läuft über Diffs. Beim bekannten Test SWE-bench bekommt ein Modell echte Fehlermeldungen aus offenen Projekten und muss einen passenden Patch erzeugen. Gemessen wird, ob die Software danach die Prüfprogramme besteht. Wenn in News von Prozentwerten bei solchen Benchmarks die Rede ist, geht es im Kern um die Qualität automatisch erzeugter Code-Diffs.

Subscribe free. Unsubscribe the second it sucks.

High-signal news across AI, business, UX, and tech. Every morning.