Wie man mit Git arbeitet und warum

Git ist eines dieser Werkzeuge, das am Anfang wie ein unbezwingbarer Berg aussieht. Viele Begriffe wirken abstrakt, und der Workflow erscheint kompliziert. Doch sobald man die Grundprinzipien verstanden hat, wird Git zu einem deiner verlässlichsten Begleiter im Entwickleralltag. In diesem Beitrag möchte ich dir die wichtigsten Git Basics vermitteln - praxisnah und so verständlich wie möglich.

Was ist Git überhaupt?

Git ist ein verteiltes Versionsverwaltungssystem, das dir hilft, den Zustand deines Codes über die Zeit hinweg nachzuvollziehen. Anstatt Dateien manuell zu kopieren oder mit Ordnern wie "Projekt_final", "Projekt_final2" oder "Projekt_wirklich_final" zu arbeiten, speichert Git professionelle, saubere und nachvollziehbare Versionsstände deiner Arbeit. Es ermöglicht dir, Änderungen rückgängig zu machen, neue Funktionen gefahrlos auszuprobieren und im Team gemeinsam an einem Projekt zu entwickeln - ohne sich gegenseitig den Code zu überschreiben.

Was Git eigentlich speichert

Git speichert nicht einfach Dateien, sondern Momentaufnahmen deines Projekts - sogenannte Snapshots. Immer wenn du einen Commit machst, merkt sich Git: So sahen die Dateien zu genau diesem Zeitpunkt aus. So kannst du später jederzeit darauf zurückspringen. Das ist wichtig zu verstehen, denn Git ist kein Backupsystem, sondern ein Versionssystem.

Ein neues Projekt mit Git starten

Du hast ein kleines Java-Projekt und möchtest es versionieren? Dann beginnst du in deinem Projektordner mit einem einfachen Kommando:

git init

Damit wird ein neues Git-Repository erstellt. Ab diesem Moment beobachtet Git deinen Projektordner.

Angenommen, du hast eine Datei Main.java:

// Datei: Main.java
public class Main {
    public static void main(String[] args) {
        System.out.println("Hallo Git");
    }
}

Wenn du Git jetzt sagst, dass du diese Datei verfolgen möchtest, machst du das mit:

git add Main.java
git commit -m "Erster Commit"

Und schon hast du deinen ersten Snapshot.

Was bedeutet "add" eigentlich?

Ein typisches Missverständnis bei Anfängern: git add speichert noch nichts dauerhaft. Es legt die Datei nur in die sogenannte Staging Area. Du sagst Git also: „Diese Änderung möchte ich im nächsten Commit haben.“

Wenn du mehrere Dateien bearbeitet hast, kannst du sie alle gleichzeitig vorbereiten:

git add .

Das fügt alle geänderten Dateien zum Staging hinzu, aber committen musst du trotzdem separat. Erst danach landen die Änderungen im Versionsverlauf.

Der Commit als kleinster Baustein

Ein Commit sollte möglichst klein und in sich logisch abgeschlossen sein. Das heißt: Lieber mehrere kleine Commits statt eines riesigen Blocks. Gute Commits helfen nicht nur dir später, sondern auch deinen Kollegen - gerade im Team ist das ein Zeichen von Professionalität.

Ein typischer Commit sieht so aus:

git commit -m "Fix: Nullpointer vermeiden beim Laden der Benutzerdaten"

Halte die Nachricht kurz, aber aussagekräftig. Sie beschreibt was du getan hast, nicht warum.

Der erste Blick auf den Verlauf

Wenn du wissen willst, was bislang im Projekt passiert ist, reicht ein einfaches:

git log

Die Ausgabe koennte so aussehen:

commit 35afbc1 Initialer Commit
commit 91be2a3 Fix: Nullpointer vermeiden
commit a71dc04 Feature: Benutzerliste sortieren

Damit siehst du schnell, welche Snapshots es gibt.

Git und Java: Ein kleines praktisches Beispiel

Nehmen wir an, du arbeitest an einer kleinen Klasse, die einen Benutzer begrüßt:

// Datei: Greeter.java
public class Greeter {
    public String greet(String name) {
        return "Hallo " + name;
    }

    public static void main(String[] args) {
        Greeter g = new Greeter();
        System.out.println(g.greet("Marcy"));
    }
}

Beim Ausführen würde folgendes erscheinen:

Hallo Marcy

Du commitest diese Datei wie gewohnt:

git add Greeter.java
git commit -m "Feature: Greeter hinzugefuegt"

Nun änderst du den Text minimal:

// Datei: Greeter.java (geaendert)
public class Greeter {
    public String greet(String name) {
        return "Hallo lieber " + name;
    }
}

Das führst du wieder aus:

Hallo lieber Marcy

Wenn du jetzt die Unterschiede sehen willst, nutzt du:

git diff

Git zeigt dir Zeile für Zeile, was sich verändert hat. Gerade für Anfänger ist das unheimlich wertvoll.

Branches: Dein sicherer Spielplatz

Mit Branches baust du dir kleine sichere Nebenwege neben deinem Hauptprojekt. Du kannst neue Features ausprobieren, ohne dass du den stabilen Hauptzweig zerstörst. Ein neuer Branch ist schnell erstellt:

git checkout -b feature-login

Nun befindest du dich auf einem eigenen Entwicklungszweig. Alle Commits landen hier und nicht im Hauptbranch. Wenn du zufrieden bist, wechselst du zurück:

git checkout main

Und fügst die Änderungen zusammen:

git merge feature-login

Git versucht automatisch, beide Stände zu verbinden. Falls sich zwei Änderungen widersprechen, entstehen Merge-Konflikte - die löst du manuell, aber das gehört zu einem anderen Artikel.

Der Reset als Notbremse

Jeder macht Fehler - und Git gibt dir die Möglichkeiten, sie rückgängig zu machen. Stell dir vor, du hast aus Versehen etwas committed, was noch nicht in den Code sollte. Dann kannst du einen Reset machen:

git reset --soft HEAD~1

Damit wird der letzte Commit zurückgerollt, aber deine Dateien bleiben unverändert im Staging liegen. Du kannst also neu und sauber committen.

Arbeiten mit dem Remote Repository

Wenn du im Team arbeitest, landet der Code meist auf einem zentralen Server wie GitHub oder GitLab. Nachdem du ein Remote hinzugefügt hast, läuft das Hochladen so:

git push origin main

Und wenn du neuen Code deiner Kollegen brauchst:

git pull

Damit hältst du deinen lokalen Stand aktuell.

Fazit

Git wirkt am Anfang kompliziert, aber sobald du die grundlegenden Konzepte verstehst - Snapshot, Staging, Commit, Branch - wird alles logisch. Übe es regelmäßig und scheue dich nicht, Fehler zu machen. Git ist ein Werkzeug, das dir Freiheit und Sicherheit bietet, und mit der Zeit wird es ganz natürlich in deinen Alltag übergehen.

Wenn du diese Basics verinnerlichst, bist du auf einem sehr guten Weg. Und keine Sorge: Das ist ein Lernprozess, den jeder Entwickler durchmacht - du bist da absolut nicht allein.