Einige Entwickler bevorzugen Code-Reviews mit „interdiff“

Warum manche Menschen Code-Reviews mit „interdiff“ mögen

Bewertung des Code-Review-Tools Gerrit

• Gerrit ist ein Open-Source-Code-Review-Tool, das mit Git-Repositories arbeitet
• Man kann Patches im Repository erstellen und sie zur Begutachtung einreichen
• Andere prüfen den geschriebenen Code und weisen auf Probleme hin, die behoben werden müssen
• Code-Reviews sind im Allgemeinen eine gute Idee
• In Open-Source-Projekten kann Code zusammengeführt werden, was Verantwortung und technische Schulden erhöht

Verschiedene Code-Review-Tools

• Es gibt verschiedene Werkzeuge wie Gerrit, GitHub, Phabricator, das Hochladen von .patch-Dateien in Bug-Trackern oder das Versenden per E-Mail über git send-email
• Jedes Tool funktioniert in unterschiedlichem Ausmaß gut

Ideale Patch-Serie

• Eine Serie aus drei Patches zeigt die Entwicklung der Codebasis Schritt für Schritt
• Änderungen sollten logisch getrennt sein, und jeder Patch sollte sich so lesen, als wäre er einzeln angewendet worden
• Durch Code-Review wird eine solche ideale Serie geprüft

GitHubs Code-Review-Ansatz: „diff soup“

• GitHub fördert ursprünglich Reviews, bei denen neue Commits auf bestehende Commits aufgesetzt werden
• Das ergibt sich aus dem UX-Design und verschiedenen weiteren Gründen
• Wenn im Review-Prozess mehrere Commits hinzukommen, werden die impliziten Beziehungen zwischen den Commits komplex
• Die Werkzeuge git blame und git bisect lassen sich dadurch schwerer nutzen

Der bessere Weg: „interdiff“-Review (auch bekannt als git range-diff)

• Statt neue Commits hinzuzufügen, veröffentlicht man neue Versionen der ursprünglichen Commits
• Mit git range-diff werden die Unterschiede zwischen den Commit-Versionen verglichen
• Reviewer können inkrementelle Reviews durchführen, ohne das gesamte Diff erneut lesen zu müssen
• Die Werkzeuge git blame und git bisect arbeiten dadurch zuverlässiger

Einschub: Strategien zum Zusammenführen von Patches

• Der oben beschriebene Ansatz ist unabhängig von der Merge-Strategie (z. B. git rebase vs. Multi-Parent-git merge-Commits)

Einschub: Ist git rebase böse?

• git rebase ist in Ordnung. Man sollte es nur nicht auf öffentlichen Branches verwenden, auf deren Commits andere aufbauen

Sonstige Hinweise

Fazit

• Ein interdiff-Review-System fördert kleinere Patches, die schneller in den Main-Branch gemergt werden
• Es bietet sowohl Reviewern als auch Autoren eine bessere Code-Review-Erfahrung

Zusammenfassung von GN⁺

• Dieser Artikel bietet eine tiefgehende Analyse von Code-Review-Tools und -Methoden
• Der interdiff-Review-Ansatz kann die Effizienz von Code-Reviews deutlich verbessern
• Er hilft dabei, GitHubs „diff soup“-Problem zu lösen
• Er zeigt wichtige Faktoren auf, die bei der Auswahl eines Code-Review-Tools berücksichtigt werden sollten
• Werkzeuge mit ähnlichen Funktionen sind unter anderem GitHub, Gerrit und Phabricator

[GN⁺]

Hacker-News-Kommentare

• Der auf GitHub meistgenutzte Workflow ist aufwendig und für Mitwirkende nicht klar genug

  • Er ermöglicht es Reviewern, die Unterschiede nach dem Einarbeiten von Feedback zu sehen, ohne git blame und git bisect zu zerstören
  • Beim Einarbeiten von Reviewer-Feedback wird git commit --fixup <Hash des zu aktualisierenden Commits> verwendet
  • Sobald der PR genehmigt ist, wird git rebase --interactive origin/main --autosquash verwendet, um Fixup-Commits mit den ursprünglichen Commits zusammenzuführen
  • Abschließend wird mit git push --force-with-lease zusammengeführt
  • Mit Autovervollständigung lassen sich lange Befehle leicht eingeben

• Die Art von Code-Reviews auf GitHub ist ineffizient, daher wurde Phabricator als manueller Workaround genutzt

  • Eine explizite UI wäre besser

• Gewünscht wird ein besseres System als GitHubs Code-Review-Ansatz

  • Kleine Bugfix-Patches sollen schnell gemergt und der Review-Umfang enger gehalten werden
  • Es wird zwar behauptet, man solle separate Reviews/PRs erstellen, aber dadurch entstehen Abhängigkeitsprobleme zwischen Patchsets

• Es ist immer interessant, neue Ansätze für Code-Reviews zu sehen

  • Es wurde erwogen, Patches in separate abhängige PRs aufzuteilen
  • Mit Tools wie GitContext lassen sich PRs klein halten und Abhängigkeiten dennoch beibehalten
  • Mit AI lassen sich PRs und Reviews zusammenfassen und präzise Commit-Messages erzeugen
  • Reviewer können nur die Änderungen seit dem letzten Review sehen

• Review Board hat interdiffs zuerst eingeführt, und sie sind für Code-Reviews äußerst nützlich

  • Fix-it-Commits sind keine geeignete Alternative
    1. Änderungen am Upstream sind nicht erkennbar
    2. Der Commit-Graph wird komplexer
    3. Nicht alle verwenden Git
  • Interdiffs ermöglichen es Reviewern, alle Aktualisierungen seit der ersten Review-Anfrage nachzuverfolgen
  • Das ist nützlich, wenn mehrere Commits als eine einzige Review-Anfrage veröffentlicht werden

• Es gibt Erfahrung mit dem Gerrit-Code-Review-System, und GitHubs Code-Reviews sind ineffizient

  • Gerrit unterstützt das Stapeln mehrerer Patches, wodurch kleine Patches leicht reviewt werden können
  • GitHubs Oberfläche wirkt wie ein Forum-Thread und kann Rebase-Vorgänge nicht nachverfolgen

• Es besteht Erfahrung mit verschiedenen Code-Review-Systemen, und jedes hat Vor- und Nachteile

  • Critique ist für Googles Monorepo und ein angepasstes VCS optimiert
  • Gerrit ist gut für Reviewer, aber unbequem für Autoren
  • GitHub ist autorenfreundlich, aber für Reviewer und Teams ineffizient
  • Wichtig ist, bessere Code-Review-Tools zu verwenden

• Nach der Nutzung des Gerrit-Code-Review-Systems wirken gestapelte PRs auf GitHub umständlich

  • GitHub zeigt Änderungen zu Code-Review-Kommentaren nicht richtig an
  • Mit einigen Skripten lässt sich die Arbeit mit gestapelten PRs erleichtern
  • Tools wie ejoffe/spr und spacedentist/spr sind nützlich