Commits und Branches vor einem Review vergleichen

Entscheiden Sie vor dem Review, welche Frage Sie stellen. „Was hat dieser Commit geändert?“ und „Was hat dieser Branch seit der Abzweigung geändert?“ können selbst bei denselben Branch-Namen unterschiedliche Diffs liefern.

Suchen Sie eine Mac-App zum Lesen gespeicherter Änderungen? Lesen Sie zuerst Ablauf und Grenzen von Yenpos Git-Diff-Viewer, bevor Sie den Schritten unten folgen.

Einen Vergleich öffnen

So prüfen Sie einen Branch feature gegenüber main. Ersetzen Sie die Beispielnamen durch Ihre Branches:

Öffnen Sie das lokale Git-Repository und klicken Sie in der Seitenleiste auf Versionen vergleichen….
Wechseln Sie von Commit zu Vergleichen.
Wählen Sie unter Von (base) Lokale Branches und main. Wählen Sie unter Nach (head) Lokale Branches und feature. Jede Spalte hat eine eigene Branch-Quelle und ein Suchfeld.
Wählen Sie Seit der Verzweigung für die Arbeit auf feature oder Direkter Vergleich für die beiden Spitzen. Der nächste Abschnitt erklärt die Unterschiede.
Prüfen Sie Branch-Namen und kurze Commit-IDs in der Zusammenfassung. Stimmt die Richtung nicht, wählen Sie die Branches unter Von und Nach neu. Klicken Sie dann auf Änderungen anzeigen.
Wählen Sie eine Datei im Baum geänderter Dateien, um ihren Inline-Diff zu lesen.

Für origin/main wählen Sie Remote-Branches in der Spalte „Von“. Dies sind bereits lokal gespeicherte Remote-Tracking-Referenzen, keine Live-Ansicht des Servers. Laden Sie bei Bedarf neuere Remote-Commits mit Ihrem üblichen Git-Client und öffnen Sie die Vergleichsauswahl erneut.

Yenpo bindet den Vergleich an bestimmte Commits. Bewegt sich ein Branch später, bleibt das Review auf den gewählten Commits. Öffnen Sie für die neue Spitze einen neuen Vergleich.

Einen Modus wählen

Frage	Modus	Vergleicht
Was hat ein Commit geändert?	Commit	Erster Eltern-Commit → dieser Commit; Root-Commit gegenüber leerem Baum
Wie unterscheiden sich zwei Branch-Spitzen jetzt?	Direkter Vergleich	base-Spitze → head-Spitze
Was hat head seit der Verzweigung geändert?	Seit der Verzweigung	Merge-Base → head-Spitze

Betrachten Sie diese Historie:

      M1──M2  main
     /
O───X
     \
      F1──F2  feature

Ein direkter Vergleich von main → feature vergleicht M2 mit F2 und enthält damit Arbeit beider Seiten. Seit der Verzweigung vergleicht X mit F2, meist passend zur Frage „Was hat feature hinzugefügt?“. Das simuliert keinen fertigen Merge und sagt keine Merge-Konflikte voraus.

Bei einem Merge-Commit vergleicht Commit nur mit dem ersten Eltern-Commit. Dies ist eine Sicht auf den Merge, kein Diff zu jedem Eltern-Commit. Prüfen Sie, ob das Ihre Frage beantwortet.

Das genaue Revisionspaar prüfen

Bewegen Sie den Zeiger auf die Revisionszeile über dem Dateibaum, um vollständige Commit-IDs zu sehen. Bei Direkter Vergleich sind dies die gewählten Von- und Nach-Commits. Bei Seit der Verzweigung trägt die Basis die Bezeichnung merge-base(...); ihre ID ist der gemeinsame Vorfahr, nicht die Spitze des Von-Branches.

Führen Sie zum Prüfen derselben Versionen diese lesenden Git-Befehle im Repository aus. Ersetzen Sie BASE_COMMIT_OID und HEAD_COMMIT_OID durch die vollständigen IDs aus Yenpo:

git show --no-patch --format='%h %s' BASE_COMMIT_OID HEAD_COMMIT_OID
git diff --stat BASE_COMMIT_OID HEAD_COMMIT_OID --

Der erste Befehl identifiziert beide Commits; der zweite fasst den Unterschied ihrer gespeicherten Bäume zusammen. Uncommittete Dateien liegen außerhalb dieses Vergleichs. Nutzen Sie bei älteren Reviews die aufgezeichneten IDs: Branch-Namen können inzwischen auf neuere Commits zeigen.

Den Diff im Kontext lesen

Der Dateibaum öffnet schreibgeschützte Inline-Diffs. Vergleichsdateien können neben aktuellen Dateien offen sein. Prüfen Sie deshalb die Tab-Version, bevor Sie über Aufrufer oder Tests urteilen. Ihr Arbeitsbaum kann bereits Änderungen enthalten, die im gewählten head fehlen.

Lesen Sie bei jeder verhaltensrelevanten Änderung über die bearbeiteten Zeilen hinaus:

Finden Sie einen Aufrufer, der den neuen Code erreicht.
Bestimmen Sie die auslösende Eingabe oder den Zustand.
Verfolgen Sie Rückgabewert, Fehler oder Seiteneffekt zurück zum Aufrufer.
Prüfen Sie, ob ein bestehender Test diesen Zustand wirklich erreicht.

Ein Test namens „handles concurrent reads“ macht vielleicht nur zwei Aufrufe nacheinander. Lesen Sie Aufbau und Assertions statt nur den Namen. Das Promise-Cache-Review zeigt dies praktisch.

Den AI Reader um ein Review bitten

Nutzen Sie in der Vergleichskopfzeile Diesen Vergleich von der KI prüfen lassen. Der Button bereitet einen Entwurf mit angehängtem Vergleich vor und sendet noch nichts. Prüfen Sie den Vergleichs-Chip, passen Sie die Frage an und senden Sie den Entwurf. Ohne verbundenes Modell folgen Sie zuerst Modellanbieter verbinden.

Zum Beispiel:

Prüfe diese Änderung auf Regressionen bei Abbruch und Fehlerbehandlung. Nenne pro Befund die geänderte Stelle, den auslösenden Zustand, das sichtbare Verhalten und den belegenden Code. Liste bereits in der Basis vorhandene Probleme getrennt auf.

Prüfen Sie, ob jeder vorgeschlagene Auslöser in den gewählten Commits wirklich auftreten kann. Bleibt die Reihenfolge beim Lesen unklar, fragen Sie nach Reproduktion oder gezieltem Test und führen Sie diesen selbst aus. Ein Test in einer Antwort wurde noch nicht ausgeführt.

Wenn Sie etwas beheben möchten

Git-Vergleichsgespräche bleiben immer schreibgeschützt. Starten Sie für die Korrektur ein normales Gespräch zum aktuellen Arbeitsbaum und aktivieren Sie Änderungen erlauben. Behalten Sie den Vergleich als Referenz.

Lesen Sie danach den Arbeitsbaum-Diff und führen Sie Projektprüfungen selbst aus. Stoppen setzt bereits geschriebene Dateien nicht zurück. Gab es vorher andere Änderungen, trennen Sie diese von der Korrektur, bevor Sie über den Commit entscheiden.