Dein erster Commit: Staging, Diff und Historie verstehen

Wenn du deine ersten Schritte mit Android Studio machst, taucht Git früher oder später auf. Bevor du dich mit Branches, Remotes oder Pull Requests beschäftigst, lohnt es sich, den Lebensweg einer einzelnen Änderung zu verstehen: Wie wandert eine Zeile Kotlin aus deinem Editor in die dauerhafte Projekt-Historie? Genau dieser Weg führt über drei klar getrennte Bereiche und endet mit deinem ersten Commit.

Was ist das?

Ein Commit ist ein dauerhafter Schnappschuss deines Projekts zu einem bestimmten Zeitpunkt, eindeutig identifiziert durch einen Hash. Dein „erster Commit” ist nicht nur das initiale Befüllen eines neuen Repositories, sondern auch die erste echte Lerneinheit darüber, wie Git Änderungen verwaltet. Git unterscheidet streng zwischen drei Zuständen: dem Working Tree (deine Dateien auf der Festplatte), dem Staging-Bereich (auch Index genannt) und der Commit-Historie. Diese Trennung ist kein Selbstzweck — sie gibt dir die Kontrolle darüber, welche Änderungen zusammen gehören und welche du noch zurückhalten willst.

In Android-Projekten ist das besonders relevant, weil ein einziger Feature-Branch schnell Anpassungen an Compose-Screens, ViewModels, Gradle-Skripten und Ressourcen sammelt. Ohne saubere Commits verschwimmen diese Schichten in der Historie zu einem unlesbaren Klumpen, der spätere Reviews, Bisects oder Reverts unnötig schwer macht.

Wie funktioniert es?

Stell dir die drei Zustände als Schleuse vor. Wenn du in Android Studio eine MainActivity.kt editierst und speicherst, landet die Änderung zuerst nur im Working Tree. Git sieht die Datei als „modified”, aber sie ist noch nicht für den nächsten Commit vorgemerkt. Mit git add MainActivity.kt schiebst du den aktuellen Stand der Datei in den Staging-Bereich. Erst git commit schreibt den gestageten Inhalt gemeinsam mit einer Nachricht in die Historie und erzeugt einen neuen Commit-Hash.

Der Diff ist das Werkzeug, mit dem du jeden Übergang prüfst. git diff ohne weitere Argumente zeigt, was sich zwischen Working Tree und Staging-Bereich unterscheidet — also Änderungen, die du noch nicht gestaget hast. git diff --staged (oder --cached) zeigt dagegen, was zwischen Staging und letztem Commit liegt — also genau das, was beim nächsten Commit landet. Diese beiden Sichten getrennt zu verstehen, ist der Kern des mentalen Modells.

Android Studio kapselt all das im „Commit”-Tool-Window. Die Liste oben enthält die Dateien, die in deinen nächsten Commit fließen, das untere Panel zeigt den Diff. Die Häkchen entsprechen dem Staging-Bereich. Wer die Kommandozeile kennt, versteht das UI sofort — und umgekehrt.

Warum drei Zustände?

Die Trennung erlaubt dir, große Änderungen schrittweise zu zerlegen. Du kannst eine Datei teilweise stagen (git add -p), den Rest später committen und dazwischen den Diff erneut prüfen. Diese Disziplin zahlt sich spätestens dann aus, wenn du in einem Team arbeitest und ein Reviewer deine Commits einzeln nachvollziehen können soll.

In der Praxis

Angenommen, du hast in einem neuen Compose-Projekt zwei Dinge gleichzeitig erledigt: ein neues Composable in Greeting.kt geschrieben und versehentlich local.properties mit deinem absoluten SDK-Pfad geändert. Du willst nur das Composable committen.

git status
# modified: app/src/main/java/.../Greeting.kt
# modified: local.properties

git diff app/src/main/java/.../Greeting.kt
# Review der inhaltlichen Änderung

git add app/src/main/java/.../Greeting.kt
git diff --staged
# Bestätigt: nur Greeting.kt liegt im Staging

git commit -m "feat: add Greeting composable with name parameter"

Die Stolperfalle, die fast jeden Anfänger einmal trifft: git add . oder git commit -am. Beide Kurzformen ziehen alles Modifizierte mit hinein, inklusive local.properties, generierter Build-Outputs oder vergessener Debug-Logs. Pflege deshalb von Anfang an eine vernünftige .gitignore — Android Studio legt sie beim Anlegen eines Projekts bereits an — und stage Dateien bewusst und gezielt. Eine zweite häufige Falle sind nichtssagende Commit-Nachrichten wie „fix” oder „update”. Schreibe stattdessen, was sich ändert und warum — dein zukünftiges Ich beim Code-Review wird es dir danken.

Eine bewährte Faustregel für den Einstieg: Ein Commit beantwortet eine einzige Frage. Wenn du in deiner Nachricht „und” schreiben musst, sind es vermutlich zwei Commits.

Fazit

Der Weg vom Editor in die Historie führt über drei Stufen — Working Tree, Staging, Commit — und der Diff ist dein Mikroskop dafür. Lege ein leeres Übungs-Repository an, ändere zwei Dateien, stage nur eine, prüfe git diff und git diff --staged nebeneinander und committe. Wiederhole denselben Ablauf in Android Studio über das Commit-Tool-Window und vergleiche, was die GUI dir zeigt, mit dem, was die Kommandozeile ausgibt. Wenn beide Sichten für dich denselben mentalen Zustand abbilden, hast du das Modell verinnerlicht — und alles, was später kommt (Branches, Rebase, Reviews), baut auf genau diesem Verständnis auf.