Git Grundlagen – Versionskontrolle verstehen und effektiv nutzen
Git ist das wichtigste Werkzeug in der modernen Softwareentwicklung. Ob Soloprojekt oder Team mit hundert Entwicklern – ohne Versionskontrolle ist professionelles Arbeiten kaum vorstellbar. Git protokolliert jede Änderung, ermöglicht das Parallel-Arbeiten an Features und macht Fehler rückgängig, ohne Daten zu verlieren.
Dieser Guide führt dich von der Installation bis zum souveränen Umgang mit Branches und Remote-Repositories.
Was ist Git – und warum brauche ich es?
Git ist ein verteiltes Versionskontrollsystem. Das bedeutet:
- Jeder Entwickler hat eine vollständige Kopie des Repositories mit der gesamten History
- Es gibt keine zentrale Abhängigkeit – du kannst lokal ohne Netzwerk arbeiten
- Änderungen werden als "Commits" gespeichert – ein unveränderlicher Schnappschuss des Projektzustands
Ohne Git:
- Ordner wie
projekt_final_v2_WIRKLICH_FINAL.zip - Fehler, die nicht mehr rückgängig gemacht werden können
- Zusammenarbeit per E-Mail mit manuellen Merge-Orgien
Mit Git:
- Vollständige History jeder Änderung
- Branches für Features ohne das Hauptprojekt zu gefährden
- Pull Requests als strukturierter Review-Prozess
- Rollback zu jedem beliebigen Zeitpunkt
Installation und Erstkonfiguration
Installation
# Ubuntu / Debian
sudo apt update && sudo apt install -y git
# Fedora
sudo dnf install -y git
# Version prüfen
git --version
# git version 2.53.0
Pflichteinstellung: Name und E-Mail
Git signiert jeden Commit mit Name und E-Mail. Diese Einstellung ist Pflicht vor dem ersten Commit:
# Global für alle Repositories
git config --global user.name "Dein Name"
git config --global user.email "deine@email.de"
# Standard-Branch auf 'main' setzen (moderner Standard)
git config --global init.defaultBranch main
# Bevorzugten Editor setzen (z.B. nano für Einsteiger, vim für Fortgeschrittene)
git config --global core.editor nano
Konfiguration prüfen
git config --list
# user.name=Dein Name
# user.email=deine@email.de
# init.defaultBranch=main
Die Konfiguration wird in ~/.gitconfig gespeichert:
cat ~/.gitconfig
Erstes Repository anlegen
Neues Repo erstellen
mkdir mein-projekt
cd mein-projekt
git init
# Initialized empty Git repository in /home/andre/mein-projekt/.git/
Bestehendes Repo klonen
# Von GitHub
git clone https://github.com/nutzer/repo.git
# Mit SSH (empfohlen, wenn SSH-Key eingerichtet ist)
git clone git@github.com:nutzer/repo.git
# In spezifischen Ordner klonen
git clone https://github.com/nutzer/repo.git mein-ordner
.gitignore – Was Git ignorieren soll
Fast jedes Projekt hat Dateien, die nicht ins Repository gehören: Abhängigkeiten, Secrets, Build-Artefakte.
# .gitignore im Projektroot erstellen
nano .gitignore
Beispiel für ein Python-Projekt:
# Virtuelle Umgebungen
.venv/
venv/
__pycache__/
*.pyc
# Secrets und Konfiguration
.env
*.key
*.pem
# IDE-Dateien
.vscode/
.idea/
*.swp
# Build-Artefakte
dist/
build/
*.egg-info/
Tipp: github.com/github/gitignore enthält vorgefertigte
.gitignore-Templates für fast jede Sprache und Framework.
Der Git-Workflow: Stage → Commit → History
Der grundlegende Git-Zyklus besteht aus drei Schritten:
Arbeitsverzeichnis → Staging Area → Repository (History)
(Änderungen) (git add) (git commit)
Status anzeigen
git status
Ausgabe-Bedeutung:
Untracked files– neue Dateien, die Git noch nicht kenntChanges not staged– geänderte Dateien, noch nicht gestagedChanges to be committed– gestaged, bereit für Commit
Änderungen stagen (git add)
# Einzelne Datei stagen
git add datei.txt
# Mehrere Dateien
git add datei1.txt datei2.py
# Ganzes Verzeichnis
git add src/
# Alle Änderungen stagen (Vorsicht: staged auch ungewollte Dateien!)
git add .
# Interaktiv stagen (zeilenweise)
git add -p datei.txt
Commit erstellen
# Commit mit Nachricht
git commit -m "Füge Login-Funktion hinzu"
# Staging und Commit in einem (nur für bereits getrackte Dateien)
git commit -am "Bugfix: Nullpointer in user.validate() behoben"
# Commit mit ausführlicher Nachricht (Editor öffnet sich)
git commit
Gute Commit-Messages:
# Format: kurze Zusammenfassung (max. 72 Zeichen), optional Leerzeile + Details
feat: Benutzer-Authentifizierung mit JWT implementiert
- Token-Ablaufzeit auf 24h gesetzt
- Refresh-Token-Mechanismus ergänzt
- Middleware für geschützte Routen hinzugefügt
Closes #42
Konvention: Conventional Commits (feat, fix, docs, style, refactor, test, chore)
History anzeigen
# Alle Commits (kompakt)
git log --oneline
# Mit Branching-Visualisierung
git log --oneline --graph --all
# Ausführliche Ansicht
git log
# Letzten 5 Commits
git log -5
# Änderungen eines Commits anzeigen
git show abc1234
# Wer hat welche Zeile zuletzt geändert?
git blame datei.txt
Änderungen ansehen (git diff)
# Unstaged Änderungen
git diff
# Staged Änderungen (was wird committet?)
git diff --staged
# Unterschied zwischen zwei Commits
git diff abc1234 def5678
# Unterschied zwischen Branches
git diff main feature/login
Branches: parallel arbeiten
Branches ermöglichen es, an Features zu arbeiten, ohne den Hauptzweig zu destabilisieren.
main ────●────────────────●────●── (stabil, produktionsreif)
\ /
feature ●────●────●──/ (Feature-Branch)
Branch-Grundlagen
# Alle Branches anzeigen
git branch
git branch -a # auch Remote-Branches
# Neuen Branch erstellen
git branch feature/login
# Zum Branch wechseln (moderner Befehl: git switch, seit Git 2.23)
git switch feature/login
# Branch erstellen UND wechseln (ein Schritt)
git switch -c feature/login
# Alternativ (alter Befehl, noch weit verbreitet)
git checkout -b feature/login
# Branch löschen (nach dem Merge)
git branch -d feature/login
# Branch löschen erzwingen (auch ungemergt)
git branch -D feature/login
Branches zusammenführen (Merge)
# Zum Zielbranch wechseln
git switch main
# Feature-Branch mergen
git merge feature/login
# Merge mit explizitem Merge-Commit (kein Fast-Forward)
git merge --no-ff feature/login
Merge-Konflikte auflösen
Wenn zwei Branches dieselbe Zeile unterschiedlich geändert haben, entsteht ein Konflikt:
<<<<<<< HEAD (main)
const port = 3000;
=======
const port = 8080;
>>>>>>> feature/config
Auflösen:
- Datei öffnen und Konflikt-Markierungen manuell bearbeiten
- Gewünschten Code behalten, Markierungen entfernen
- Datei stagen:
git add datei.js - Merge abschließen:
git commit
# Merge abbrechen und zum Ausgangszustand zurück
git merge --abort
Rebase (Alternative zu Merge)
Rebase schreibt die Commit-History um und fügt Commits an das Ende des Zielbranches an – sauberere History, aber vorsichtig bei shared Branches:
git switch feature/login
git rebase main
Faustregel: Merge für öffentliche/shared Branches. Rebase nur für lokale, noch nicht gepushte Branches.
Remote-Repositories: GitHub und GitLab
Remote hinzufügen
# Remote "origin" hinzufügen
git remote add origin git@github.com:dein-nutzer/repo.git
# Alle Remotes anzeigen
git remote -v
# Remote-URL ändern
git remote set-url origin git@github.com:dein-nutzer/neues-repo.git
Pushen und Pullen
# Ersten Push (Branch tracken)
git push -u origin main
# Danach reicht
git push
# Änderungen vom Remote holen
git pull
# Holen ohne Merge (nur herunterladen)
git fetch origin
# Nach fetch: lokalen Branch mit Remote-Stand zusammenführen
git merge origin/main
Typischer Workflow mit GitHub/GitLab
# 1. Feature-Branch erstellen
git switch -c feature/payment
# 2. Arbeiten, stagen, committen
git add .
git commit -m "feat: Stripe-Integration für Zahlungen"
# 3. Auf Remote pushen
git push -u origin feature/payment
# 4. Pull Request / Merge Request im Web erstellen
# → Review durch Kollegen → Merge → Branch löschen
# 5. Lokal aufräumen
git switch main
git pull
git branch -d feature/payment
Typische Workflows im Alltag
Letzten Commit korrigieren
# Commit-Nachricht ändern (nur wenn noch nicht gepusht!)
git commit --amend -m "Neue, bessere Commit-Message"
# Vergessene Datei zum letzten Commit hinzufügen
git add vergessen.txt
git commit --amend --no-edit
Änderungen temporär parken (git stash)
# Aktuelle Änderungen weglegen (ohne Commit)
git stash
# Gestashte Änderungen wiederherstellen
git stash pop
# Alle Stashes anzeigen
git stash list
# Spezifischen Stash anwenden
git stash apply stash@{0}
Dateien aus Staging entfernen
# Datei aus Staging nehmen (Änderung bleibt erhalten)
git restore --staged datei.txt
# Änderung einer Datei verwerfen (VORSICHT: unwiderruflich!)
git restore datei.txt
Zu einem älteren Commit zurück (Rollback)
# History anzeigen, Commit-Hash notieren
git log --oneline
# Datei aus altem Commit wiederherstellen
git restore --source abc1234 datei.txt
# Ganzes Repo zu altem Stand (als neuer Branch)
git switch -c recovery abc1234
Häufige Fehler und wie du sie behebst
„fatal: not a git repository"
# Prüfen ob .git-Verzeichnis existiert
ls -la | grep .git
# Falls nicht: Repository initialisieren
git init
Commit auf falschen Branch gemacht
# Commit vom aktuellen Branch entfernen, aber Änderungen behalten
git reset HEAD~1
# Zum richtigen Branch wechseln und dort committen
git switch richtiger-branch
git add .
git commit -m "..."
Datei versehentlich gelöscht
# Gelöschte Datei wiederherstellen
git restore datei.txt
Push wird abgelehnt (Remote ist weiter)
! [rejected] main -> main (fetch first)
# Remote-Änderungen erst holen und mergen
git pull --rebase
git push
Sensible Daten committet (Passwörter, API-Keys)
# Sofort: Datei aus letztem Commit entfernen
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Remove .env from tracking"
git push
# Falls bereits auf Remote: API-Key sofort rotieren/invalidieren!
# Dann: git filter-repo nutzen (komplexer, separater Guide)
Die wichtigsten Git-Befehle im Überblick
# Setup
git config --global user.name "Name"
git config --global user.email "mail@beispiel.de"
git init
git clone <url>
# Status & History
git status
git log --oneline --graph --all
git diff [--staged]
# Stage & Commit
git add <datei> # stagen
git add . # alles stagen
git commit -m "msg" # committen
git commit --amend # letzten Commit ändern
# Branches
git branch # anzeigen
git switch -c <branch> # erstellen + wechseln
git merge <branch> # mergen
git branch -d <branch> # löschen
# Remote
git remote add origin <url>
git push -u origin main
git pull
git fetch
# Rückgängig machen
git restore <datei> # Änderung verwerfen
git restore --staged <datei> # aus Staging nehmen
git reset HEAD~1 # letzten Commit rückgängig (Änderungen bleiben)
git stash / git stash pop # Änderungen parken
Fazit
Git ist keine Option, sondern Standard. Wer einmal den Workflow verinnerlicht hat – Stage, Commit, Push, Branch – arbeitet effizienter und sicherer. Die Lernkurve ist flach, der Nutzen ist enorm.
Nächste Schritte:
- SSH-Schlüssel erstellen und sicher verwenden – SSH für GitHub/GitLab einrichten
- Python Entwicklungsumgebung unter Linux
- Node.js unter Linux installieren mit nvm
Git 2.53.0 | Tested on: Ubuntu 24.04 LTS, Debian 13 Trixie | Last updated: 2026-02-18