Git diff

Sehen wir uns nun eine detailliertere Aufschlüsselung der Diff-Ausgabe an.

Diese Zeile zeigt die Eingabequellen des Diff an. Wir können erkennen, dass a/diff_test.txt und b/diff_test.txt an Diff übergeben wurden.

Diese Zeile zeigt einige interne Git-Metadaten an. Diese Information wirst du höchstwahrscheinlich nicht brauchen. Die Zahlen in dieser Ausgabe entsprechen den Hash-Kennungen der Git-Objektversion.

Diese Zeilen stellen eine Legende dar, die jeder Diff-Eingabequelle Symbole zuweist. In diesem Fall werden Änderungen in a/diff_test.txt durch --- und Änderungen in b/diff_test.txt durch +++ gekennzeichnet.

Die verbleibende Diff-Ausgabe ist eine Liste mit verschiedenen Diff-Blöcken. Ein Vergleich zeigt nur die Abschnitte der Datei an, die Änderungen enthalten. Im vorliegenden Beispiel haben wir nur einen Block, da wir mit einem einfachen Szenario arbeiten. Blöcke haben ihre eigene granulare Ausgabesemantik.

Die erste Zeile ist der Blockheader. Jedem Block ist ein von @@-Symbolen umschlossener Header vorangestellt. Der Inhalt des Headers ist eine Zusammenfassung der Änderungen, die an der Datei vorgenommen wurden. In unserem vereinfachten Beispiel sehen wir -1 +1. Das bedeutet, dass es in Zeile eins Änderungen gab. In einem realistischeren Vergleich würdest du Header wie etwa folgenden sehen:

Bei diesem Header-Beispiel wurden 6 Zeilen ab Zeilennummer 34 extrahiert. Außerdem wurden 8 Zeilen ab Zeile 34 hinzugefügt.

Der verbleibende Inhalt des Diff-Blocks zeigt die kürzlichen Änderungen an. Jeder geänderten Zeile wird ein + oder - vorangestellt. Dies weist darauf hin, von welcher Version der Diff-Eingabe die Änderungen stammen. Wie vorhin besprochen, weist - auf Änderungen in a/diff_test.txt und + auf Änderungen in b/diff_test.txt hin.

Die Ausgabe zeigt jetzt nur die farbkodierten Wörter an, die geändert wurden.

Wenn du die Git-Quelle klonst, findest du ein Unterverzeichnis namens contrib. Es enthält einige zu Git gehörende Tools und andere interessante Dinge, die noch nicht zum Git-Kern gehören. Eines davon ist ein Perl-Skript namens diff-highlight. Diff-highlight bringt gleiche Zeilen von Diff-Ausgaben zusammen und hebt Teilwortfragmente hervor, die geändert wurden.

Jetzt haben wir unseren Diff auf die kleinste mögliche Änderung abgespeckt.

Git hat ein Feature, mit dem du einen Shellbefehl spezifizieren kannst, um Inhalte in deinen Binärdateien zu transformieren, bevor der Vergleich durchgeführt wird. Dazu sind jedoch einige vorbereitende Maßnahmen erforderlich. Lege zunächst einen textconv-Filter fest, der beschreibt, wie eine bestimmte Art von Binärdatei in Text konvertiert wird. Wir verwenden ein einfaches Dienstprogramm namens pdftohtml (über Homebrew erhältlich), um PDFs in ein visuell lesbares HTML-Format zu konvertieren. Du kannst dies für ein einzelnes Repository einrichten, indem du deine Datei .git/config bearbeitest, oder global, indem du ~ /.gitconfig bearbeitest.

Danach musst du lediglich ein oder mehrere Dateimuster mit unserem pdfconv-Filter zuordnen. Hierzu erstellst du eine .gitattributes-Datei im Stamm deines Repositorys.

Nach der Konfiguration wird git diff zunächst die Binärdatei mithilfe des festgelegten Konverterskripts ausführen und die Konverterausgabe vergleichen. Du kannst dieselbe Technik anwenden, um nützliche Vergleiche von allen möglichen Arten an Binärdateien zu erhalten, wie ZIP- und JAR-Dateien und anderen Archiven. Durch die Verwendung von unzip -l (oder ähnlich) anstelle von pdf2html werden Pfade angezeigt, die zwischen Commits-Images hinzugefügt oder entfernt wurden. Mit exiv2 kannst du Änderungen von Metadaten wie Dokumente zu Bildabmessungen anzeigen. Es gibt Konvertierungstools, um ODF-, DOC- und andere Dokumentformate in Nur-Text umzuwandeln. Falls es keine formalen Konverter gibt, können häufig Strings für Binärdateien verwendet werden.

Dieses Beispiel ist auf ./path/to/file ausgelegt und wird bei Aufruf die spezifischen Änderungen im Arbeitsverzeichnis mit dem Index vergleichen und Änderungen anzeigen, die noch nicht bereitgestellt sind. git diff führt den Vergleich standardmäßig mit HEAD aus. Wird HEAD wie im obigen Beispiel weggelassen, hat git diff ./path/to/file denselben Effekt.

Wenn git diff mit der Option --cached aufgerufen wird, werden die bereitgestellten Änderungen mit dem lokalen Repository verglichen. Die Option --cached bedeutet dasselbe wie --staged.

Bei einem Aufruf von git diff ohne Dateipfad werden Änderungen im gesamten Repository verglichen. Die obigen, dateispezifischen Beispiele können mit dem Argument ./path/to/file aufgerufen werden und liefern dieselben Ausgabeergebnisse für alle Dateien im lokalen Repository.

Der Befehl git diff zeigt dir standardmäßig Änderungen seit dem letzten Commit, die nicht committet wurden.

An git diff können Git-Verweise an Commits übergeben werden, die verglichen werden sollen. Einige Beispielverweise sind HEAD, Tags und Branch-Namen. Jeder Commit in Git verfügt über eine Commit-ID, die du durch die Ausführung von GIT LOG erhalten kannst. Du kannst diese Commit-ID auch an git diff übergeben.

In diesem Beispiel wird der Punktoperator vorgestellt. Die zwei Punkte darin zeigen an, dass es sich bei der Vergleichseingabe um die Enden beider Branches handelt. Derselbe Effekt tritt auf, wenn die Punkte ausgelassen und stattdessen ein Leerzeichen zwischen den Branches gesetzt wird. Es gibt im Übrigen einen Operator mit drei Punkten:

Der Operator mit drei Punkten initiiert den Vergleich, indem er den ersten Eingabeparameter branch1 ändert. Dadurch wird aus branch1 ein Verweis des Vorgänger-Commits, der von den zwei Vergleichseingaben gemeinsam genutzt wird, dem gemeinsamen Vorgänger von branch1 und anderen Feature Branches. Der letzte Eingabeparameter bleibt unverändert wie die Enden anderer Feature Branches.