Warum ein GitHub-PR ohne Leerzeichen kleiner aussieht
Ein kleiner Funktionswechsel kann in einem Meer aus roten und grünen Zeilen verschwinden, wenn ein Formatter zugleich die Einrückung ändert. GitHub hat am 22. Oktober eine Verbesserung angekündigt: Die persönliche Einstellung zur Leerzeichenanzeige lässt sich über mehrere Pull Requests hinweg speichern.
Die Einstellung bleibt beim nächsten PR erhalten
Unter Files changed → Settings → Whitespace changes stehen Always show, Always hide und Hide for this diff only zur Wahl. Die gespeicherte Einstellung gilt persönlich und PR-übergreifend. Bei ausgeblendeten Leerzeichen erscheint neben All commits der Filter Hide whitespace. Sein X blendet sie vorübergehend wieder ein, ohne die gespeicherte Wahl zu ändern.
Auch Dateianzahl und Diff-Statistik folgen der angezeigten Ansicht. Kleinere Zahlen bedeuten daher nicht zwingend, dass der Autor Änderungen entfernt hat. Ein Blick auf den aktiven Filter kann erklären, warum zwei Personen denselben PR unterschiedlich beschreiben.
Die relevante Zeile hinter der Formatierung
Für das Beispiel haben wir JavaScript zur Preisberechnung geschrieben. Die neue Fassung rundet das Ergebnis auf zwei Nachkommastellen; zugleich wächst die Einrückung von zwei auf vier Leerzeichen. Das Bild zeigt tatsächlich lokal ausgeführtes git diff, keine GitHub-Oberfläche.
Im normalen Diff erscheinen Berechnung und Rückgabe als geänderte Zeilen. Mit git diff -w bleibt die Berechnung als Kontext stehen, während die neue Rückgabe hervorsticht. So lässt sich besser über Rundung, negative Werte und bestehende Tests sprechen. Eine ruhigere Ansicht erleichtert das Lesen, beweist aber keine Korrektheit.
Leerzeichen können Verhalten sein
Einrückungen in Python, Ebenen in YAML und Leerzeichen in Zeichenketten können Bedeutung tragen. Aus "Hello world" wird durch eine einzige Löschung "Helloworld". -w steuert den Vergleich, versteht aber nicht die Semantik der Programmiersprache.
Bei diesem bewusst einfachen Zeichenkettenbeispiel erzeugt -w tatsächlich keine Diff-Ausgabe. Das zweite Bild dokumentiert unseren Lauf. Daraus folgt keine vollständige Gleichheit zwischen GitHub und lokalem Git. Es zeigt, warum man bedeutungstragende Abstände vor der Freigabe noch einmal ungefiltert lesen sollte.
Mehr Breite für neue Dateien
Neue und gelöschte Dateien nutzen in split view jetzt beide Spalten. Ohne alte Vergleichsseite ist die zusätzliche Breite sinnvoll und reduziert Zeilenumbrüche bei langen Typen oder Testnamen.
Bei gemischten Formatierungs- und Funktionsänderungen hilft zuerst die gefilterte Sicht auf die Logik und danach die vollständige Sicht auf Zeichenketten und Struktur. Getrennte Formatierungs-Commits machen die Absicht deutlicher. Die neue Einstellung spart Klicks; die Bedeutung der Änderung bleibt Aufgabe des Reviews.
Offizielle Quellen
GitHub Docs · Reviewing proposed changes
Am 23. Oktober 2026 anhand der offiziellen Ankündigung und Git-Dokumentation geprüft; beide Vergleiche lokal ausgeführt.