GitHub Workflow für Android-Lernende: Remote, Push und Pull Request verstehen

GitHub gehört zur Grundausstattung moderner Android-Teams. Sobald du mehr als eine kleine App allein baust, brauchst du einen verlässlichen Weg, deinen Code zu sichern, mit anderen zu teilen und Änderungen sauber zu prüfen. Genau dafür greifen drei Begriffe ineinander: Remote, Push und Pull Request. Wenn du verstehst, wie sie zusammenspielen, hast du das Fundament für Code-Review, Continuous Integration und stabile Releases gelegt.

Was ist das?

GitHub ist ein Hosting-Dienst, der deine Git-Repositorys in der Cloud speichert und um Werkzeuge für Zusammenarbeit ergänzt. Lokal arbeitest du mit Git auf deiner Maschine: Du machst Commits, wechselst Branches und pflegst deine History. GitHub stellt zusätzlich eine gemeinsame, gehostete Kopie deines Repositorys bereit — das sogenannte Remote. Über dieses Remote synchronisieren mehrere Entwicklerinnen und Entwickler ihre Arbeit, ohne sich gegenseitig zu überschreiben.

Im Android-Alltag bedeutet das: Dein Gradle-Projekt, deine Compose-UI, deine Repositorys, deine Tests — alles liegt in einem Git-Repository, das auf GitHub gespiegelt ist. Sobald du ein neues Feature umsetzt, einen Bug behebst oder eine Coroutine korrigierst, läuft die Übergabe an das Team über GitHub. Der GitHub-Workflow beschreibt also, wie du lokale Git-Historie mit dem Remote verknüpfst und Änderungen geordnet in den Hauptzweig bringst. Er ist die Brücke zwischen „Ich habe etwas auf meinem Rechner gebaut” und „Wir releasen das gemeinsam in den Play Store”.

Wie funktioniert es?

Das Modell baut auf vier Bausteinen auf: Repository, Remote, Branch und Pull Request. Beim ersten git clone lädst du das gesamte Repository samt History herunter. Git merkt sich die Quelle als Remote, üblicherweise unter dem Namen origin. Mit git remote -v siehst du jederzeit, welche URL hinterlegt ist. Ein Repository kann mehrere Remotes haben, etwa origin für deinen Fork und upstream für das Originalprojekt.

Eine Änderung beginnt fast immer auf einem Feature-Branch, zum Beispiel feature/login-screen. Du arbeitest lokal, machst kleine, fokussierte Commits und prüfst dein Compose-UI im Emulator oder auf einem realen Gerät. Wenn der Branch sauber ist und die Tests grün sind, lädst du ihn mit git push origin feature/login-screen zum Remote hoch. push überträgt dabei nur deinen Branch und nur die Commits, die GitHub noch nicht kennt; Branches anderer Personen bleiben unberührt.

Den eigentlichen Übergang in main regelt der Pull Request. Auf GitHub öffnest du einen PR, beschreibst, was sich geändert hat, und verlinkst Issue oder Ticket. Reviewer kommentieren Zeile für Zeile, fordern Änderungen an oder geben den PR frei. Parallel laufen automatische Checks: Android Lint, ktlint oder detekt, Unit-Tests, vielleicht ein Compose-UI-Test über die Gradle Managed Devices. Erst wenn Review und CI grün sind, wird der PR gemergt — häufig per Squash- oder Rebase-Merge, damit main eine lineare, lesbare History behält. Andere holen den neuen Stand danach mit git pull oder mit git fetch plus git merge ab.

Branch-Strategie kurz gefasst

Trennen ist wichtiger als Verschachteln. main bleibt immer baubar und releasefähig. Feature-Branches sind kurzlebig und decken genau eine Änderung ab. Lange Branches sind ein Warnsignal — sie führen zu Merge-Konflikten und schwer reviewbaren Diffs. Eine bewährte Faustregel: Wenn dein Branch älter als ein paar Tage ist, denk darüber nach, ihn aufzuteilen oder zumindest mit git rebase main aktuell zu halten.

In der Praxis

Ein typischer Mini-Workflow für ein neues Compose-Feature sieht so aus:

# Aktuellen main holen
git checkout main
git pull origin main

# Feature-Branch starten
git checkout -b feature/profile-screen

# ... Code in Android Studio schreiben, in kleinen Schritten committen ...
git add app/src/main/java/de/example/profile/ProfileScreen.kt
git commit -m "feat(profile): add ProfileScreen composable with state hoisting"

# Tests lokal laufen lassen
./gradlew :app:testDebugUnitTest

# Branch zum Remote pushen
git push -u origin feature/profile-screen

Anschließend öffnest du auf GitHub einen Pull Request mit klarer Beschreibung: Was wurde gebaut, warum, wie wurde es getestet? Hänge Screenshots der Compose-Vorschau oder eine kurze Bildschirmaufnahme an. Verlinke das passende Issue, damit der Kontext nicht verloren geht. Reagiere zügig auf Review-Kommentare und nutze für nachträgliche Korrekturen weitere Commits — Force-Push (git push --force-with-lease) ist nur auf deinem eigenen Feature-Branch akzeptabel, niemals auf main oder geteilten Branches.

Eine typische Stolperfalle ist das direkte Committen auf main. Das umgeht Review und CI, kann andere blockieren und macht Hotfixes riskanter. Schütze main deshalb in den GitHub-Repository-Einstellungen mit Branch-Protection-Rules: erforderliche Reviews, grüne Checks, keine direkten Pushes, optional signierte Commits. Eine zweite häufige Falle sind riesige Pull Requests mit dutzenden Dateien. Sie werden selten gründlich gelesen, weil das menschliche Review-Budget begrenzt ist. Halte einen PR auf eine logische Einheit fokussiert — einen Compose-Screen, eine Repository-Klasse, einen Bugfix in einem Flow-Operator. Wenn dein Diff über mehrere hundert Zeilen wächst, prüfe, ob du in zwei PRs aufteilen kannst.

Eine dritte Falle betrifft Geheimnisse: API-Keys, google-services.json mit produktiven Credentials oder Keystore-Passwörter dürfen nicht ins Repository wandern. Pflege deine .gitignore von Anfang an und prüfe vor dem git push, was wirklich im Diff steht. GitHub bietet zudem Secret-Scanning an, das versehentliche Pushes meldet — verlasse dich aber nicht ausschließlich darauf.

Fazit

Wenn du Remote, Push und Pull Request verinnerlichst, hast du den Grundpfeiler für professionelle Android-Entwicklung gesetzt. Du arbeitest lokal sicher, teilst nur das, was reif ist, und nutzt Pull Requests als Lern- und Qualitätswerkzeug zugleich. Probiere den Ablauf am besten heute aus: Lege ein kleines Compose-Projekt an, pushe es zu GitHub, eröffne einen PR auf einem Feature-Branch und lass dich selbst oder eine Kollegin reviewen. Beobachte dabei, wie die CI reagiert, lies die Diffs aufmerksam, prüfe die Kommentare im Review und sieh dir die History nach dem Merge an. Wer diese Schleife regelmäßig durchläuft, baut nicht nur sauberere Apps — sondern auch das Vertrauen und die Routine, die in Junior-Dev-Rollen den Unterschied machen.