Screenshots in Code-Review und Pull Request nutzen
UI-Änderungen lassen sich im Diff kaum beurteilen. Ein kleiner Screenshot-Satz – vorher/nachher, annotiert, mit dem entscheidenden Zustand – macht einen Pull Request prüfbar.
Ein Pull Request, der das Verhalten einer Schaltfläche, die Validierung eines Formulars oder einen Ladezustand ändert, lässt sich aus einem Diff kaum beurteilen. Reviewer checken am Ende den Branch aus, bauen neu und suchen den Bildschirm, den du gemeint hast. Ein kleiner, gut gemachter Screenshot-Satz erspart diese Arbeit.
Vorher und nachher aufnehmen
Für jede sichtbare Änderung nimmst du denselben Bildschirm zweimal auf:
- Auf dem Basis-Branch nimmst du den betroffenen Bereich auf.
- Auf deinem Branch nimmst du denselben Bereich bei gleicher Fenstergröße und gleichem Zoom auf.
- Behalte beide Aufnahmen; schneide die eine nicht enger zu als die andere.
Erst wenn Ansichtsfenster, Browser-Zoom und Fenstergröße übereinstimmen, ist der Vergleich aussagekräftig. Ist das Layout responsiv, nimm die Breiten auf, die zählen (zum Beispiel 1280 und 390), und beschrifte sie.
Nur den Unterschied annotieren
Der Reviewer muss wissen, wo er hinschauen soll, nicht eine ganze Führung bekommen:
- Nummern für mehrere Änderungen in einem Screenshot: 1 ist der neue Leerzustand, 2 die Fehlermeldung.
- Formen, um den geänderten Bereich zu umreißen.
- Text für das erwartete Verhalten, kurz gehalten.
- Mosaik oder Weichzeichnen für alles Private: Kundennamen, E-Mails, Tokens, interne URLs.
Annotiere nicht den ganzen Bildschirm. Wenn die Änderung ein einziges Bedienelement ist, reichen ein Pfeil und ein Satz.

Die Interaktion aufnehmen, wenn ein Standbild nicht reicht
Manche Änderungen ergeben nur in Bewegung Sinn: ein Dropdown, das sich früher zu früh schloss, ein Spinner, der jetzt auflöst, eine Zieh-Interaktion. Nimm 10–20 Sekunden mit Schnellaufnahme auf und hänge dann die MP4 an oder, für ein Review im Fließtext, ein GIF (Pro).
- Zeige zuerst das fehlerhafte Verhalten, dann das behobene, wenn möglich in einem Clip.
- Schalte das Mikrofon aus, wenn Kommentar nichts hinzufügt; ein stummer Clip startet gefahrlos automatisch.
- Halte den Clip kurz genug, um ihn zweimal anzusehen.
Die Belege in den Pull Request legen
Eine vorhersehbare Struktur spart dem Reviewer Zeit:
- Was sich geändert hat in einem Satz.
- Vorher-/Nachher-Bilder, nebeneinander oder untereinander, immer in derselben Reihenfolge.
- Wie man den Zustand reproduziert, falls es nicht der Standardbildschirm ist.
- Was zu prüfen ist – die ein oder zwei Dinge, die regressieren könnten.
- Umgebung, falls relevant: Betriebssystem, Browser, Bildschirmskalierung.
Hänge Bilder direkt an den Pull Request statt auf ein persönliches Laufwerk zu verlinken. Wenn du einen Freigabelink nutzt, denk daran, dass er ablaufen oder ein Passwort verlangen kann; für ein Code-Review ist ein Anhang meist besser.
Den Satz klein halten
Reviewer überfliegen. Drei fokussierte Screenshots werden gelesen; fünfzehn werden weggescrollt.
- Ein Paar pro sichtbarer Änderung.
- Schneide Browser-Oberfläche und irrelevante Bereiche weg.
- Komprimiere oder verkleinere Bilder, die nur Kontext liefern; behalte die volle Auflösung für pixelgenaue Änderungen.
- Lösche die Screenshots, die denselben Zustand aus einem leicht anderen Winkel wiederholen.
Eine Checkliste vor dem Absenden
| Prüfpunkt | Warum |
|---|---|
| Gleiches Ansichtsfenster und gleicher Zoom in Vorher/Nachher | Sonst ist der Vergleich ungültig |
| Eine Änderung pro Bild | Leichter zu diskutieren und zu klären |
| Anmerkungen zeigen auf die Änderung | Kein Suchen |
| Private Daten verborgen | Pull Requests sind oft für mehr Leute sichtbar als erwartet |
| Clip nur, wo Bewegung zählt | Kurz und ansehbar |
| Anhänge statt persönlicher Links | Reviewer sollten kein Konto brauchen |
Häufige Fragen
Sollte ich Screenshots oder eine Bildschirmaufnahme anhängen?
Standbilder für Zustände, einen kurzen Clip für Interaktionen. Eine Aufnahme von 10–20 Sekunden reicht, um einen Übergang zu zeigen; alles Längere wird meist übersprungen.
Wie verstecke ich Kundendaten in einem Review-Screenshot?
Nutze Mosaik mit starker Einstellung für Namen und IDs, eine deckende Abdeckung für Geheimnisse oder schneide den Bereich aus. Weichzeichnen ist schwächer als Mosaik und sollte für nichts Sensibles verwendet werden.
Brauche ich Pro für Review-Screenshots?
Nein für Aufnahme, Anmerkungen, Nummerierung, Mosaik und einfache MP4-Aufnahmen. GIF-Export, Intelligentes Entfernen und die Effekte des Videoeditors sind Pro-Funktionen, aber ein Standbild-Satz plus MP4 deckt die meisten Reviews kostenlos ab.
Mehr aus dem Blog

Text in Screenshots einfügen – und wirklich lesbar machen
Beschriftungen, Titel und Hinweise in Screenshots einfügen: lesbarer Kontrast, richtige Größe, saubere Platzierung – und später bearbeiten auf Mac und Windows.
25. Oktober 2026
Automatischer Zoom in Bildschirmaufnahmen: Was er kann
So folgt der automatische Zoom in einer Bildschirmaufnahme deinen Klicks, wie die Stärke das Ergebnis verändert und wann eine statische Aufnahme besser ist.
25. Oktober 2026
So erstellst du ein Vorher-Nachher-Vergleichsbild
Ein Bild statt zwei Anhängen: Nimm beide Zustände in gleicher Größe auf, füge sie nebeneinander, beschrifte sie – und verschicke einen Vergleich, den man schnell erfasst.
25. Oktober 2026