Pull-Request-Hygiene für Android-Projekte

Pull-Request-Hygiene bedeutet, dass du Änderungen so vorbereitest, dass andere sie mit vertretbarem Aufwand verstehen, prüfen und sicher freigeben können. In Android-Projekten betrifft das nicht nur Git, sondern auch deinen Umgang mit Kotlin-Code, Compose-UI, Architekturgrenzen, Tests und Release-Risiken.

Was ist das?

Ein Pull Request ist ein Vorschlag, Code in einen gemeinsamen Branch zu übernehmen. Pull-Request-Hygiene beschreibt die Qualität dieses Vorschlags: Ist die Änderung klein genug? Ist sie fachlich klar beschrieben? Zeigt der Diff genau das, was geprüft werden soll? Wenn diese Fragen gut beantwortet sind, wird ein Review zu einer fachlichen Kontrolle statt zu einer Suchaufgabe.

Das mentale Modell ist einfach: Ein Pull Request ist keine Ablage für alles, was dir beim Arbeiten begegnet. Er ist eine prüfbare Einheit. Eine prüfbare Einheit hat ein Ziel, einen nachvollziehbaren Weg und eine erkennbare Grenze. Wenn du zum Beispiel einen Fehler in einem Compose-Screen behebst, sollte derselbe Pull Request nicht zusätzlich ein Repository umbenennen, ein Theme refactoren und fünf ungenutzte Imports im ganzen Projekt entfernen. Jede dieser Änderungen kann sinnvoll sein, aber zusammen machen sie den Diff schwerer lesbar.

Für Android-Lernende ist dieses Thema wichtig, weil mobile Apps viele Ebenen verbinden. Ein kleiner UI-Text kann von einer String-Resource, einem ViewModel-State, einer Navigation-Route und einem Test abhängen. Wenn du deine Änderungen unstrukturiert bündelst, kann ein Reviewer kaum erkennen, ob ein Problem aus der UI, der Datenquelle oder einer Architekturentscheidung kommt. Gute Pull-Request-Hygiene hilft dir, diese Ebenen sauber sichtbar zu machen.

Im Kontext moderner Android-Entwicklung passt das Thema eng zu Jetpack Compose und Architecture Components. Compose macht UI-Code oft kompakt, aber Diffs können trotzdem unübersichtlich werden, wenn du Layout, State-Hoisting, Styling und fachliche Logik gleichzeitig änderst. Architekturleitlinien helfen dir, Verantwortlichkeiten zu trennen. Pull-Request-Hygiene sorgt dafür, dass diese Trennung auch im Review erkennbar bleibt.

Wie funktioniert es?

Die wichtigste Mechanik ist der kleine, fokussierte Diff. Ein Diff zeigt, welche Zeilen hinzugefügt, geändert oder gelöscht wurden. Reviewer lesen nicht deine Absicht, sondern zuerst diese sichtbaren Änderungen. Je mehr unterschiedliche Absichten in einem Diff stecken, desto größer wird die kognitive Last. Deshalb solltest du Änderungen nach Zweck trennen: Bugfix, Refactoring, Testergänzung, UI-Anpassung oder technische Vorbereitung.

Klein bedeutet dabei nicht automatisch wenige Zeilen. Ein Pull Request kann viele Zeilen enthalten und trotzdem gut sein, wenn alle Änderungen dieselbe Aufgabe erfüllen. Ein Beispiel ist das Umbenennen eines falsch benannten Use Cases samt Tests und Aufrufen. Umgekehrt kann ein kurzer Pull Request schlecht sein, wenn er eine versteckte Architekturänderung enthält, aber nur als „kleiner Fix“ beschrieben ist. Die Frage lautet nicht nur „Wie groß ist der Diff?“, sondern „Wie viele Entscheidungen muss man gleichzeitig prüfen?“.

Die Beschreibung ist der zweite Kern. Eine gute Beschreibung beantwortet drei Fragen: Warum gibt es die Änderung? Was wurde geändert? Wie wurde sie geprüft? Für Android ist der Prüfweg besonders wertvoll. Hast du einen Compose-Preview geprüft? Einen UI-Test ausgeführt? Einen ViewModel-Test ergänzt? Eine manuelle Prüfung auf einem kleinen Display gemacht? Solche Hinweise sparen Zeit und zeigen, dass du die Wirkung deiner Änderung verstanden hast.

Der dritte Punkt ist die Reihenfolge. Gute Pull Requests erzählen eine nachvollziehbare Geschichte. Erst wird das Problem erklärt, dann die Lösung, dann der Nachweis. Wenn du mehrere Commits nutzt, sollten sie ebenfalls lesbar sein. Ein Commit wie „fix stuff“ hilft wenig. Ein Commit wie „Extrahiere LoginUiState aus LoginViewModel“ erklärt dagegen eine konkrete Teiländerung. Du musst nicht jeden Commit perfekt formulieren, aber der gesamte Pull Request sollte für eine andere Person ohne Zusatzgespräch verständlich sein.

Im Alltag bedeutet Pull-Request-Hygiene auch, den Diff vor dem Öffnen selbst zu lesen. Das ist kein bürokratischer Schritt, sondern eine technische Kontrolle. Du erkennst versehentliche Formatierungen, Debug-Logs, temporäre Testdaten, nicht benötigte Imports oder Dateien, die durch ein Tool verändert wurden. Gerade in Android-Projekten entstehen solche Nebengeräusche schnell: Gradle-Dateien, generierte Konfigurationen, Ressourcen, Layout-Previews oder IDE-Einstellungen können im Diff auftauchen, obwohl sie für die Aufgabe keine Rolle spielen.

Ein weiterer Mechanismus ist die klare Grenze zwischen Refactoring und Verhalten. Refactoring ändert die Struktur, soll aber das Verhalten gleich lassen. Ein Feature oder Bugfix ändert Verhalten. Wenn du beides in einem Pull Request mischst, muss der Reviewer doppelt prüfen: Ist die neue Struktur korrekt, und ist das neue Verhalten korrekt? Besser ist oft eine Reihenfolge aus zwei Pull Requests. Zuerst ein reines Refactoring mit Tests, danach die fachliche Änderung auf der saubereren Basis.

In der Praxis

Stell dir vor, du arbeitest an einer kleinen Notizen-App mit Compose. Im Screen „NoteDetailScreen“ wird der Speichern-Button auch dann aktiviert, wenn der Titel nur aus Leerzeichen besteht. Du möchtest das beheben. Während du im Code bist, fällt dir auf, dass ein paar Farben nicht zum Design passen und das ViewModel eine Methode mit einem unklaren Namen hat. Die Versuchung ist groß, alles direkt mitzunehmen. Für Pull-Request-Hygiene wäre das aber ein Warnsignal.

Ein guter Pull Request könnte so heißen: „Deaktiviere Speichern bei leerem Notiztitel“. Die Beschreibung könnte lauten: „Der Speichern-Button im NoteDetailScreen wurde bisher aktiviert, sobald der Titel nicht leer war. Titel mit nur Leerzeichen wurden dadurch akzeptiert. Der ViewModel-State trimmt den Titel nun für die Validierung, ohne den eingegebenen Text im Feld zu verändern. Geprüft mit ViewModel-Test und manueller Compose-Prüfung auf dem Detail-Screen.“

Dieser Pull Request hat eine klare Grenze. Er ändert Validierungslogik und den betroffenen Test. Er lässt Farben und Benennungen unverändert. Wenn du die Methode später umbenennen willst, machst du dafür einen separaten Pull Request. Dadurch kann der Reviewer die eigentliche Frage prüfen: Wird der Button korrekt deaktiviert, und bleibt die Texteingabe für den Nutzer erwartbar?

Eine konkrete Entscheidungsregel lautet: Wenn du für zwei Änderungen zwei verschiedene Begründungen brauchst, sind es wahrscheinlich zwei Pull Requests. „Ich behebe eine fehlerhafte Validierung“ und „ich räume veraltete Namen auf“ sind zwei Begründungen. „Ich ändere die Validierung und passe die Tests daran an“ ist eine Begründung mit passendem Nachweis. Diese Regel ist nicht absolut, aber sie hilft dir, früh zu erkennen, wann ein Diff zu viel trägt.

Eine typische Stolperfalle ist der gemischte Formatierungs-Diff. Du änderst eine Funktion und deine IDE formatiert nebenbei die ganze Datei. Im Review sieht es dann so aus, als hättest du sehr viel mehr geändert. Das kostet Zeit und kann echte Fehler verstecken. Wenn ein Projekt ein Formatierungstool nutzt, führe es bewusst aus und erwähne es. Wenn nicht, beschränke Formatierung auf die Zeilen, die du fachlich anfasst. Reine Formatierungsänderungen gehören möglichst in eigene Pull Requests.

Eine zweite Stolperfalle ist die zu knappe Beschreibung. „Fix validation“ reicht selten aus. Der Reviewer muss dann aus dem Diff erraten, welches Verhalten vorher falsch war und welche Prüfung du durchgeführt hast. Besser ist eine kurze, aber konkrete Struktur:

• Problem: Was war vorher falsch oder unklar?
• Lösung: Welche Grenze oder Regel wurde geändert?
• Prüfung: Welche Tests oder manuellen Schritte hast du ausgeführt?
• Risiko: Gibt es Stellen, die besonders aufmerksam geprüft werden sollten?

Bei Android kannst du diese Struktur direkt auf typische Arbeitsbereiche anwenden. Für Compose-UI beschreibst du, welcher Screen, welcher State und welche Nutzeraktion betroffen sind. Für Architekturänderungen nennst du, welche Schicht sich geändert hat: UI, ViewModel, Domain, Repository oder Datenquelle. Für Tests erklärst du, ob du einen Unit-Test, einen Instrumentation-Test oder eine manuelle Prüfung genutzt hast. So bleibt der Pull Request eng am Code und trotzdem verständlich.

Ein brauchbares Beispiel für eine Pull-Request-Beschreibung wäre:

Titel: „Validiere Notiztitel vor dem Speichern“

Beschreibung: „Der Speichern-Button wurde bei Titeln aus Leerzeichen aktiviert. Die Validierung nutzt nun den getrimmten Titel, während der sichtbare Eingabetext unverändert bleibt. Ergänzt wurde ein ViewModel-Test für leere und mit Leerzeichen gefüllte Titel. Manuell geprüft im NoteDetailScreen mit normaler Eingabe, leerem Titel und Leerzeichen.“

Diese Beschreibung ist nicht lang, aber sie beantwortet die wichtigen Fragen. Sie trennt sichtbares Verhalten von interner Validierung. Sie nennt den Test. Sie zeigt, dass du den Compose-Screen wirklich geprüft hast. Genau das macht ein Review schneller und genauer.

Auch die Größe deiner Pull Requests kannst du üben. Bevor du einen Pull Request öffnest, lies den Diff so, als wärst du nicht die Person, die ihn geschrieben hat. Markiere gedanklich jede Änderung mit einem Zweck. Wenn du viele Zwecke findest, teile den Pull Request. Wenn du eine Datei berührst, frage dich, ob jede Änderung in dieser Datei zur beschriebenen Aufgabe gehört. Wenn nicht, entferne sie aus dem Branch oder verschiebe sie in eine spätere Änderung.

Bei größeren Aufgaben kannst du bewusst Vorbereitungs-Pull-Requests nutzen. Angenommen, du willst einen Screen von einer lokalen State-Lösung auf ein ViewModel mit Flow umstellen. Ein sauberer Ablauf könnte so aussehen: Zuerst extrahierst du einen UI-State, ohne Verhalten zu ändern. Danach führst du das ViewModel ein. Danach ergänzt du Tests oder passt bestehende Tests an. Jeder Schritt ist kleiner und leichter prüfbar. Das passt gut zu Android-Architektur, weil du Verantwortlichkeiten schrittweise sichtbar machst.

Wichtig ist aber, Pull-Request-Hygiene nicht mit künstlicher Kleinteiligkeit zu verwechseln. Wenn ein Feature nur zusammen sinnvoll geprüft werden kann, darf ein Pull Request mehrere Dateien ändern. Ein Compose-Screen, sein ViewModel und ein Test gehören oft zusammen. Problematisch wird es erst, wenn unabhängige Ziele vermischt werden. Gute Hygiene schützt den Review-Prozess, ohne deine Arbeit unnötig zu zerstückeln.

Für dich als Lernenden ist Code Review außerdem ein Trainingswerkzeug. Wenn ein Reviewer oft nach Kontext fragt, ist das ein Hinweis auf eine zu dünne Beschreibung. Wenn häufig versteckte Nebenänderungen kommentiert werden, solltest du deinen Diff vorab sorgfältiger lesen. Wenn Reviews sehr lange dauern, kann die Ursache in zu großen Pull Requests liegen. Diese Rückmeldungen sind kein persönliches Urteil, sondern Daten über deinen Arbeitsprozess.

Fazit

Pull-Request-Hygiene macht deine Android-Arbeit prüfbar: kleine fachliche Einheiten, klare Beschreibungen und saubere Diffs helfen anderen, deinen Kotlin-, Compose- und Architekturcode zuverlässig zu bewerten. Prüfe beim nächsten Pull Request bewusst den Diff vor dem Öffnen, formuliere Problem, Lösung und Prüfung in wenigen Sätzen und bitte im Review gezielt um Rückmeldung zu einer konkreten Entscheidung; so trainierst du nicht nur Git-Gewohnheiten, sondern auch technisches Denken, Testbarkeit und saubere Zusammenarbeit.