Text-Diff

Was dieses Werkzeug tut

Ein Diff beantwortet genau eine Frage: Was müsste sich ändern, um einen Text in einen anderen zu verwandeln? Fügen Sie das Original in das Feld „Original" ein und die neue Fassung in das Feld „Geändert", und das Werkzeug zeigt jede gelöschte Zeile, jede hinzugefügte Zeile und — innerhalb einer geänderten Zeile — die exakten Wörter, die sich unterscheiden, hervorgehoben. Es ist dieselbe Frage, die git bei jedem Commit beantwortet, berechnet mit derselben Algorithmenfamilie, vollständig in Ihrem Browser.

Der letzte Teil zählt bei einem Diff-Werkzeug mehr als bei den meisten anderen: Was Menschen vergleichen, ist meist privat — zwei Versionen einer Produktions-Konfiguration, eine Abfrage vor und nach der Optimierung, der Antwort-Body, der gestern funktionierte, gegen den, der heute fehlschlägt. Hier verlassen sie nie Ihr Gerät.

Nebeneinander oder Unified

Beide Ansichten zeigen denselben Vergleich, nur anders angeordnet. Nebeneinander stellt Original und geänderte Fassung einander gegenüber — die Originalspalte unter dem Feld „Original" — mit ausgerichteten übereinstimmenden Zeilen: die natürliche Art, die Überarbeitung eines Dokuments zu lesen. Unified verflicht beide in einer Spalte, Löschungen mit einem Minus, Ergänzungen mit einem Plus davor — das Format von git log und Code-Reviews, kompakter und besser, wenn Änderungen verstreut sind. Beide Ansichten zeigen die ursprünglichen Zeilennummern am Rand, sodass ein Fund hier direkt auf Ihre Datei zurückverweist.

Wie das Diff berechnet wird

Das Werkzeug implementiert den Differenz-Algorithmus von Myers, veröffentlicht 1986 und bis heute der Standard in git. Er findet ein kürzestes Editierskript: die minimale Zahl von Zeilenlöschungen und -einfügungen, die einen Text in den anderen überführt. Diese Minimalität macht ein Diff lesbar — ein naiver Vergleich, der sich nach einer Änderung schlecht neu synchronisiert, meldet ganze Blöcke als ersetzt, wo Myers exakt die zwei Zeilen benennt, die sich wirklich geändert haben.

Verglichen werden zuerst Zeilen, dann wird jedes Paar geänderter Zeilen noch einmal auf Wortebene verglichen, um die Hervorhebungen zu erzeugen. Eine ehrliche Grenze: Wenn zwei Texte fast nichts gemeinsam haben, würde die Suche nach dem minimalen Skript mehr Speicher kosten, als ein Browser-Tab ausgeben sollte — jenseits einer Editierdistanz von zweitausend fällt das Werkzeug deshalb darauf zurück, alles als ersetzt zu zeigen, und sagt das mit einem Hinweis statt stillschweigend.

Die Leerzeichen- und Schreibungsoptionen

Viele Unterschiede sind echt, aber belanglos. Eine von Tabs auf Leerzeichen umgestellte Datei, ein vom Editor ergänztes Leerzeichen am Zeilenende, ein anders großgeschriebenes Schlüsselwort — alles echte Änderungen, alles Rauschen, wenn Sie wissen wollen, ob sich die Logik geändert hat. Die zwei Kästchen decken die häufigen Fälle ab: eines klammert Leerzeichen an den Zeilenrändern aus, das andere die Groß-/Kleinschreibung. Sie beeinflussen nur, was als Änderung zählt — die Anzeige zeigt jede Zeile immer exakt so, wie sie eingefügt wurde.

• Rand-Leerzeichen ignorieren — Leerzeichen und Tabs am Zeilenanfang und -ende werden vor dem Vergleich verworfen; eine reine Einrückungsänderung erscheint nicht mehr als geänderte Zeile. Leerzeichen im Zeileninneren zählen weiterhin.
• Groß-/Kleinschreibung ignorieren — Zeilen und Wörter, die sich nur in der Schreibung unterscheiden, gelten als gleich. Nützlich für SQL-Schlüsselwörter, HTTP-Header-Namen und andere schreibungsunabhängige Kontexte.

Der kopierbare Patch

Der Kopierknopf erzeugt den Vergleich im Unified-Diff-Format — der Lingua franca für Codeänderungen. Jeder Änderungsblock (Hunk) beginnt mit einer @@-Kopfzeile, die die abgedeckten Zeilennummern nennt; gelöschte Zeilen beginnen mit Minus, hinzugefügte mit Plus, und einige unveränderte Kontextzeilen umgeben jeden Block, damit die Änderung auch dann auffindbar bleibt, wenn die Datei sich leicht verschoben hat.

--- a
+++ b
@@ -1,3 +1,3 @@
 server:
-  port: 8080
+  port: 9090
   timeout: 30

Dieser Text lässt sich in ein Ticket oder Review einfügen, an Kollegen schicken oder mechanisch anwenden: in eine Datei gespeichert, spielen git apply oder der Unix-Befehl patch die Änderung auf das Original zurück. Ein Detail, das man kennen sollte: Eine Datei ohne abschließenden Zeilenumbruch bekommt im Patch die Markierung \ No newline at end of file — das Werkzeug reproduziert dieses Verhalten, denn ein fehlender letzter Zeilenumbruch ist ein echter Unterschied, und ihn zu leugnen erzeugt Patches, die nicht anwendbar sind.