Diff Checker

So verwendest du den Diff-Prüfer

1. Füge die Originaldatei in den linken Editor ein. Diese wird als Basis behandelt - der "Vorher"-Zustand.
2. Füge die geänderte Datei in den rechten Editor ein. Alles, was das Werkzeug meldet, ist relativ dazu, wie diese von der linken abweicht.
3. Klicke auf Vergleichen. Das Diff-Fenster rendert darunter mit zeilenebenen Ergänzungen in Grün, Löschungen in Rot und unverändertem Kontext in Grau.
4. Lies die Rinnsal-Zahlen. Jede geänderte Zeile zeigt die ursprüngliche Zeilennummer und die neue Zeilennummer; gelöschte Zeilen zeigen nur die ursprüngliche, hinzugefügte Zeilen nur die neue, damit du direkt zum offending Ort in deiner echten Datei springen kannst.
5. Als vereinheitlichten Diff kopieren, um einen Patch im genauen Format zu erhalten, das git apply, patch und Code-Review-Werkzeuge verbrauchen. Füge diesen in einen PR-Kommentar ein, wenn inline Review-Kommentare nicht ausdrucksstark genug sind.
6. Verwende Tauschen, um die Seiten umzudrehen, was praktisch ist für die Überprüfung "Würde das Anwenden dieses Patches in umgekehrter Reihenfolge Sinn ergeben?" Verwende Löschen, um beide Editoren zurückzusetzen.

Wie der Vergleich funktioniert

Der Prüfer implementiert den klassischen Myers-Diff-Algorithmus aus Eugene Myers' Papier von 1986 "An O(ND) Difference Algorithm and Its Variations" - derselbe Algorithmus, den Git seit dem ersten Tag als Standard verwendet. Er teilt beide Eingaben nach Zeilenumbrüchen auf, behandelt jede Zeile als atomisches Token und durchläuft einen Bearbeitungsgraph, um das kürzeste Bearbeitungsskript zu finden, das das Original in das Geänderte verwandelt. Das Ergebnis ist eine Sequenz von Hunks: zusammenhängende Läufe unveränderter Zeilen mit eingefügten und gelöschten Zeilen dazwischen. Das Ausgabe-Rendering erfolgt in JavaScript ohne innerHTML-Zuweisungen, sodass das Einfügen von Zeilen mit <script> oder anderem HTML-artigem Text kein Markup injizieren kann. Die Schaltfläche Als vereinheitlichten Diff kopieren umschließt jeden Hunk im kanonischen @@ -a,b +c,d @@-Header, der von GNU diff, Git und Mercurial verwendet wird.

Wann du es verwenden würdest

• Überprüfen eines Pull Requests offline, wenn du die beiden Dateien auf der Festplatte hast, aber keine Git-Geschichte sie verbindet.
• Vergleichen zweier Versionen einer Konfigurationsdatei - Nginx, Terraform, YAML - die dir ein Teamkollege ohne Kontext per E-Mail geschickt hat.
• Erstellen eines sauberen vereinheitlichten Diffs zum Einfügen in ein JIRA-Ticket oder einen Chat-Kanal als Beweis dafür, was sich geändert hat.
• Überprüfen, dass deine Build-Artefakt-Ausgabe über zwei Läufe byteidentisch ist, indem die generierten Dateien verglichen werden.
• Verifizieren, dass das Ausführen eines Formatierers (prettier, gofmt, black) keine unbeabsichtigten Inhaltsänderungen zusätzlich zur Formatierung eingeführt hat.
• Entdecken der kleinsten Änderung, die eine Regression verursacht hat, indem das letzte grüne Deployment mit dem ersten roten verglichen wird.

Häufige Fallstricke und Randfälle

• Abschließende Zeilenumbruch-Unterschiede. Eine Datei mit einem abschließenden Zeilenumbruch und eine ohne sind nicht identisch; das Werkzeug zeigt dies als Änderung an der letzten Zeile an, was dem "\\ Kein Zeilenumbruch am Dateiende"-Marker von diff entspricht.
• CRLF vs. LF. Das Einfügen von Windows-Zeilenenden auf einer Seite und Unix-Stil auf der anderen markiert jede Zeile als geändert. Normalisiere vorher mit einem Werkzeug wie dos2unix, oder erwarte ein Meer von Rot und Grün.
• Tab versus Leerzeichen-Einrückung. Myers Diff ist zeilenbasiert und markiert ein Tab-zu-Leerzeichen-Reflow als vollständige Neuschreibung jeder Zeile. Verwende ein Leerraumignorierendes Werkzeug wie git diff -w, wenn das die Absicht ist.
• Sehr lange Dateien. Myers ist O(ND), wobei N die Gesamtanzahl der Token und D die Bearbeitungsdistanz ist. Eingaben mit Zehntausenden von Zeilen und großem D können mehrere Sekunden im Browser dauern, bevor etwas gerendert wird.
• Binäre Daten. Zeilenbasierte Diffs sind bei kompilierten Binärdateien, Bildern oder gepackten Archiven bedeutungslos. Das Werkzeug produziert immer noch eine Ausgabe, aber es ist Rauschen.
• Identische Dateien. Die Ausgabe zeigt die gesamte Datei als unveränderte graue Zeilen ohne Hunks - eine nützliche Bestätigung, dass sich nichts verschoben hat.

Hintergrund zum vereinheitlichten Diff-Format

Das vereinheitlichte Diff-Format wurde von Wayne Davison für GNU diff in den frühen 1990ern eingeführt und ist jetzt de facto über Git, Mercurial, SVN und jedes Code-Review-Werkzeug standardisiert. Ein vereinheitlichter Diff öffnet mit zwei Datei-Headern, die mit --- und +++ beginnen, gefolgt von einem oder mehreren Hunks. Jeder Hunk beginnt mit einem Header der Form @@ -originalStart,originalZeilen +neuStart,neuZeilen @@, gefolgt von den Zeilen selbst: leerzeichen-präfixiert für Kontext, minus-präfixiert für entfernte Zeilen, plus-präfixiert für hinzugefügte Zeilen. Standardmäßig verwendet GNU diff drei Zeilen Kontext, was auch der Git-Standard ist. POSIX 1003.1 standardisiert das Format, und Werkzeuge wie patch können es konsumieren, um die Änderung anderswo erneut anzuwenden. Die Ausgabe dieses Werkzeugs ist bytekompatibel mit diesen Verbrauchern, also kannst du kopieren, in patch -p0 einfügen und die Änderung landen sehen.

Vergleich mit Alternativen

git diff ist das richtige Werkzeug, wenn beide Seiten in einem Repository leben - es kennt Umbenennungen, behandelt Binärerkennung und unterstützt -w für leerrauminsensitiven Vergleich. GNU diff -u ist der POSIX-Arbeitspferd für Ad-hoc-Dateipaare auf deiner Festplatte. meld, kdiff3 und Beyond Compare bieten Drei-Wege-Merge-Ansichten, die dieses Browser-Werkzeug nicht erreichen kann. Der eingebaute Diff-Editor von VS Code hat Syntaxhervorhebung und inline wortebene Anpassungen. Verwende diesen Web-Prüfer, wenn die Dateien noch nicht auf deinem Rechner sind - du hast sie aus Slack, E-Mail oder einem Log-Viewer eingefügt - und du einfach einen vereinheitlichter-Diff-Kopier-einfügebereiten Patch möchtest, ohne ein Terminal zu öffnen. Wenn deine Aufgabe ein Drei-Wege-Merge oder eine repo-weite leerraumignorier Überprüfung ist, greife zu den dedizierten Werkzeugen.