Git-Grundlagen: commit, branch, merge

Git-Grundlagen gehören zu den wichtigsten Fähigkeiten in der modernen Softwareentwicklung, denn Git ist ein verteiltes Versionskontrollsystem, das jede Änderung an deinem Code festhält. Egal ob du allein oder im Team arbeitest, Git gibt dir die Möglichkeit, Fehler rückgängig zu machen, nachzuvollziehen, wer wann was geändert hat, und parallel an denselben Dateien zu arbeiten. In diesem Artikel erklären wir die Begriffe Repository, Staging-Area, Commit und Branch klar und zeigen jeden Schritt mit echten Befehlen.

Kernkonzepte: Repository, Staging-Area, Commit

Beim Erlernen der Git-Grundlagen musst du zuerst den Wortschatz festigen. Drei Begriffe werden oft verwechselt:

• Repository: die Datenbank, die die gesamte Historie deines Projekts speichert und im versteckten Ordner .git liegt.
• Arbeitsverzeichnis (working directory): die tatsächlichen Dateien, die du gerade bearbeitest.
• Staging-Area (Index): eine Zwischenebene, in der du genau auswählst, welche Änderungen in den nächsten Commit kommen.
• Commit: eine dauerhaft gespeicherte Momentaufnahme der gestageten Änderungen, versehen mit einer Nachricht und einer eindeutigen Kennung (Hash).

Der Ablauf ist: Du bearbeitest eine Datei → du stagest sie mit git add → du schreibst sie mit git commit ins Repository.

Ein neues Repository initialisieren und der erste Commit

Zu Beginn eines neuen Projekts initialisierst du Git im Ordner. Deine erste Aufgabe ist es, deine Identität festzulegen und das Repository zu erstellen:

git config --global user.name "Dein Name"
git config --global user.email "du@beispiel.com"

mkdir meinprojekt
cd meinprojekt
git init

Der Befehl git init erstellt ein leeres .git-Repository im Ordner. Fügen wir nun eine Datei hinzu und prüfen den Status:

git status
git add index.html
git add .
git commit -m "Erster Commit: Projektgerüst"

git status zeigt, welche Dateien geändert wurden und welche gestaget sind, und ist der Befehl, den du am häufigsten verwenden wirst. git add . stagt alle Änderungen; git commit -m schließt die Aufzeichnung mit einer einzeiligen Nachricht ab. Schreibe aussagekräftige, kurze Nachrichten im Imperativ (z. B. „Validierung des Login-Formulars hinzufügen").

Die Historie lesen: git log und git status

Um die von dir erstellten Commits zu sehen, verwendest du git log:

git log
git log --oneline --graph --decorate

--oneline verdichtet jeden Commit auf eine einzige Zeile, während --graph die Branch-Struktur visuell zeichnet. Die kurze Zeichenkette am Anfang jeder Zeile ist die eindeutige Kennung (Hash) dieses Commits, und damit kannst du zu jedem Punkt zurückkehren. git status beantwortet immer die Frage „Wo stehe ich gerade?".

Branch und Merge: die Grundlage des parallelen Arbeitens

Ein Branch ist ein beweglicher Zeiger, mit dem du dich vom Hauptcode abspalten und unabhängig arbeiten kannst. Wenn du eine neue Funktion ausprobierst, arbeitest du auf einem separaten Branch, ohne den Hauptbranch (meist main) zu zerstören:

git branch feature-login
git switch feature-login

# Dasselbe in älteren Git-Versionen:
git checkout -b feature-login

Hier ist git switch der moderne, gut lesbare Befehl; git checkout -b erstellt den Branch und wechselt in einem Schritt dorthin. Nachdem du ein paar Commits auf dem Branch gemacht hast, bringst du die Änderungen nach Fertigstellung mit einem Merge (Zusammenführung) in den Hauptbranch zurück:

git switch main
git merge feature-login

# Räume den zusammengeführten Branch auf:
git branch -d feature-login

Wenn zwei Branches dieselben Zeilen derselben Datei unterschiedlich ändern, meldet Git einen Konflikt. In diesem Fall öffnest du die Datei, behebst die Abschnitte zwischen den Markierungen <<<<<<< und >>>>>>> manuell und schließt die Zusammenführung mit git add + git commit ab.

Mit Remote-Repositories arbeiten: clone, pull, push

Da Git verteilt ist, wird Code meist in einem Remote-Repository wie GitHub oder GitLab geteilt. Um ein bestehendes Projekt herunterzuladen:

git clone https://github.com/benutzer/projekt.git

Um dein eigenes lokales Repository mit einem bestehenden Remote zu verbinden und es zu senden:

git remote add origin https://github.com/benutzer/projekt.git
git push -u origin main

Der tägliche Ablauf ist einfach: Verwende git pull, um die Änderungen deiner Teamkollegen zu holen, und git push, um deine eigenen Commits hochzuladen:

git pull
git push

Das -u im ersten git push -u origin main verknüpft den lokalen Branch mit dem Remote-Branch; danach genügt ein einfaches git push.

Unerwünschte Dateien mit .gitignore ausschließen

Abhängigkeitsordner, Build-Ausgaben und geheime Schlüssel dürfen niemals ins Repository gelangen. Du erstellst im Projektstamm eine Datei .gitignore, um festzulegen, welche Dateien ignoriert werden sollen:

node_modules/
vendor/
.env
*.log
/dist
.DS_Store

Eine wichtige Regel: .gitignore wirkt nur für Dateien, die noch nicht versioniert werden. Wenn du eine Datei versehentlich bereits committet hast, musst du sie zuerst mit git rm --cached datei aus der Versionierung entfernen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen git add und git commit?

git add verschiebt Änderungen in die Staging-Area, sagt also gewissermaßen „diese möchte ich speichern"; git commit schreibt diese gestageten Änderungen dann dauerhaft mit einer Nachricht ins Repository. Ohne add hält ein Commit nichts fest.

Gibt es einen Unterschied zwischen git checkout und git switch?

Beide können den Branch wechseln. git switch ist ein neuerer, klarerer Befehl, der nur für Branch-Operationen gedacht ist; git checkout wechselt Branches und stellt auch Dateien wieder her, ist also komplexer. Anfängern wird empfohlen, git switch zu verwenden.

Wie korrigiere ich meine letzte Commit-Nachricht?

Wenn du noch nicht gepusht hast, kannst du den letzten Commit mit git commit --amend -m "Neue Nachricht" neu schreiben. Nach einem Push betrifft das Ändern der Historie deine Teamkollegen, sei also vorsichtig.

Möchtest du einen soliden Git- und Deployment-Workflow für dein Projekt aufsetzen? Wenn du Hilfe bei Versionskontrolle, Codequalität und Automatisierung brauchst, nimm Kontakt mit mir auf — lass uns gemeinsam einen Workflow entwerfen, der zu deinem Projekt passt.