Git CheatSheet
Übersicht der wichtigsten Git-Befehle mit praktischen Beispielen.
Repository erstellen & klonen
# Neues Repository im aktuellen Verzeichnis initialisieren
git init
# Neues Repository mit Verzeichnis erstellen
git init mein-projekt
# Bestehendes Repository klonen
git clone https://github.com/user/repo.git
# Klonen in ein bestimmtes Verzeichnis
git clone https://github.com/user/repo.git mein-ordner
# Nur den neuesten Commit klonen (shallow clone)
git clone --depth 1 https://github.com/user/repo.git
Konfiguration
# Benutzername setzen (global)
git config --global user.name "Max Mustermann"
# E-Mail setzen (global)
git config --global user.email "max@example.com"
# Konfiguration nur für aktuelles Repo
git config user.name "Max Mustermann"
# Alle Einstellungen anzeigen
git config --list
# Standard-Branch-Name setzen
git config --global init.defaultBranch main
# Editor festlegen
git config --global core.editor "code --wait"
# Aliase erstellen
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all"
Status & Änderungen
# Aktuellen Status anzeigen
git status
# Kurzform des Status
git status -s
# Änderungen anzeigen (noch nicht gestaged)
git diff
# Änderungen anzeigen (bereits gestaged)
git diff --staged
# Änderungen einer bestimmten Datei
git diff datei.txt
# Vergleich zwischen zwei Branches
git diff main..feature-branch
# Vergleich zwischen zwei Commits
git diff abc123 def456
Dateien hinzufügen (Staging)
# Einzelne Datei hinzufügen
git add datei.txt
# Mehrere Dateien hinzufügen
git add datei1.txt datei2.txt
# Alle Dateien im aktuellen Verzeichnis
git add .
# Alle Änderungen (inkl. gelöschte Dateien)
git add -A
# Interaktiv Teile einer Datei hinzufügen
git add -p datei.txt
# Dateien nach Muster hinzufügen
git add *.js
git add src/
Commits
# Commit mit Nachricht
git commit -m "Kurze Beschreibung der Änderung"
# Alle geänderten Dateien committen (ohne git add)
git commit -am "Änderungen committen"
# Letzten Commit ändern (Nachricht oder Dateien)
git commit --amend -m "Neue Nachricht"
# Leeren Commit erstellen (z.B. für CI-Trigger)
git commit --allow-empty -m "Trigger CI"
# Commit mit mehrzeiliger Nachricht
git commit -m "Titel" -m "Detaillierte Beschreibung"
Branches
# Alle lokalen Branches anzeigen
git branch
# Alle Branches (lokal + remote)
git branch -a
# Neuen Branch erstellen
git branch feature-login
# Branch erstellen und wechseln
git checkout -b feature-login
# oder (neuere Syntax)
git switch -c feature-login
# Zu einem Branch wechseln
git checkout main
# oder
git switch main
# Branch umbenennen
git branch -m alter-name neuer-name
# Branch löschen (lokal)
git branch -d feature-login
# Branch löschen (forciert, auch ungemergte)
git branch -D feature-login
# Remote-Branch löschen
git push origin --delete feature-login
Merging
# Branch in aktuellen Branch mergen
git merge feature-login
# Merge ohne Fast-Forward (behält Branch-Historie)
git merge --no-ff feature-login
# Merge abbrechen (bei Konflikten)
git merge --abort
# Merge-Konflikte anzeigen
git diff --name-only --diff-filter=U
Rebasing
# Aktuellen Branch auf main rebasen
git rebase main
# Interaktives Rebase (letzte 3 Commits)
git rebase -i HEAD~3
# Rebase abbrechen
git rebase --abort
# Nach Konfliktlösung fortfahren
git rebase --continue
# Einzelnen Commit überspringen
git rebase --skip
Remote-Repositories
# Remote-Repositories anzeigen
git remote -v
# Neues Remote hinzufügen
git remote add origin https://github.com/user/repo.git
# Remote-URL ändern
git remote set-url origin https://github.com/user/neues-repo.git
# Remote entfernen
git remote remove origin
# Remote umbenennen
git remote rename origin upstream
Push & Pull
# Änderungen pushen
git push origin main
# Ersten Push mit Upstream setzen
git push -u origin main
# Danach reicht:
git push
# Force-Push (Vorsicht!)
git push --force
# Sicherer:
git push --force-with-lease
# Änderungen holen und mergen
git pull
# Änderungen holen ohne Merge
git fetch
# Alle Remotes fetchen
git fetch --all
# Mit Rebase statt Merge
git pull --rebase
Stashing (Änderungen zwischenspeichern)
# Aktuelle Änderungen stashen
git stash
# Stash mit Beschreibung
git stash save "Arbeit an Feature X"
# Auch untracked Dateien stashen
git stash -u
# Stash-Liste anzeigen
git stash list
# Letzten Stash anwenden und behalten
git stash apply
# Letzten Stash anwenden und löschen
git stash pop
# Bestimmten Stash anwenden
git stash apply stash@{2}
# Stash löschen
git stash drop stash@{0}
# Alle Stashes löschen
git stash clear
# Stash als neuen Branch
git stash branch neuer-branch
Historie & Logs
# Commit-Historie anzeigen
git log
# Kompakte Ansicht
git log --oneline
# Mit Graph
git log --oneline --graph --all
# Letzte n Commits
git log -5
# Commits eines Autors
git log --author="Max"
# Commits in Zeitraum
git log --since="2024-01-01" --until="2024-12-31"
# Commits mit bestimmtem Text
git log --grep="bugfix"
# Änderungen in Datei verfolgen
git log -p datei.txt
# Wer hat welche Zeile geändert
git blame datei.txt
# Kurze Statistik
git log --stat
# Änderungen pro Autor
git shortlog -sn
Rückgängig machen
# Unstaged Änderungen verwerfen
git checkout -- datei.txt
# oder (neuere Syntax)
git restore datei.txt
# Staged Datei zurück zu unstaged
git reset HEAD datei.txt
# oder
git restore --staged datei.txt
# Letzten Commit rückgängig (behält Änderungen)
git reset --soft HEAD~1
# Letzten Commit rückgängig (verwirft Änderungen)
git reset --hard HEAD~1
# Zu bestimmtem Commit zurück
git reset --hard abc1234
# Commit rückgängig machen (neuer Commit)
git revert abc1234
# Alle lokalen Änderungen verwerfen
git checkout .
git clean -fd
Tags
# Alle Tags anzeigen
git tag
# Lightweight Tag erstellen
git tag v1.0.0
# Annotated Tag mit Nachricht
git tag -a v1.0.0 -m "Version 1.0.0 Release"
# Tag für älteren Commit
git tag -a v0.9.0 abc1234 -m "Nachträglicher Tag"
# Tags pushen
git push origin v1.0.0
# Alle Tags pushen
git push origin --tags
# Tag löschen (lokal)
git tag -d v1.0.0
# Tag löschen (remote)
git push origin --delete v1.0.0
# Zu Tag wechseln
git checkout v1.0.0
Cherry-Pick
# Einzelnen Commit in aktuellen Branch übernehmen
git cherry-pick abc1234
# Mehrere Commits
git cherry-pick abc1234 def5678
# Cherry-Pick ohne Commit (nur Änderungen übernehmen)
git cherry-pick -n abc1234
# Bei Konflikten fortfahren
git cherry-pick --continue
# Cherry-Pick abbrechen
git cherry-pick --abort
Suchen
# In Dateien suchen
git grep "suchbegriff"
# Mit Zeilennummern
git grep -n "suchbegriff"
# In bestimmtem Commit suchen
git grep "suchbegriff" abc1234
# Commit finden, der einen Bug eingeführt hat
git bisect start
git bisect bad # Aktueller Commit ist kaputt
git bisect good abc1234 # Dieser Commit war noch OK
# Git führt dich durch die Commits
git bisect reset # Beenden
Aufräumen
# Untracked Dateien anzeigen
git clean -n
# Untracked Dateien löschen
git clean -f
# Auch Verzeichnisse
git clean -fd
# Auch ignorierte Dateien
git clean -fdx
# Nicht mehr existierende Remote-Branches entfernen
git fetch --prune
# Alte Objekte aufräumen
git gc
# Aggressive Aufräumung
git gc --aggressive
Submodules
# Submodule hinzufügen
git submodule add https://github.com/user/lib.git libs/lib
# Submodules beim Klonen initialisieren
git clone --recurse-submodules https://github.com/user/repo.git
# Submodules nachträglich initialisieren
git submodule init
git submodule update
# Alle Submodules aktualisieren
git submodule update --remote
# Submodule entfernen
git submodule deinit libs/lib
git rm libs/lib
Nützliche Kombinationen
# Letzten Commit-Hash anzeigen
git rev-parse HEAD
# Aktuellen Branch-Namen anzeigen
git branch --show-current
# Anzahl Commits zählen
git rev-list --count HEAD
# Alle Dateien eines Commits auflisten
git diff-tree --no-commit-id --name-only -r abc1234
# Änderungen seit letztem Tag
git log $(git describe --tags --abbrev=0)..HEAD --oneline
# Dateien im Staging-Bereich anzeigen
git diff --cached --name-only
# Lokale Branches ohne Remote löschen
git fetch -p && git branch -vv | grep ': gone]' | awk '{print $1}' | xargs git branch -D
.gitignore Beispiele
# Verzeichnisse
node_modules/
vendor/
.idea/
.vscode/
# Dateitypen
*.log
*.tmp
*.cache
# Spezifische Dateien
.env
.DS_Store
Thumbs.db
# Ausnahmen (nicht ignorieren)
!wichtig.log
# Muster
**/logs/
debug[0-9].log
Häufige Workflows
Feature-Branch Workflow
git checkout main
git pull
git checkout -b feature/neue-funktion
# ... Änderungen ...
git add .
git commit -m "Neue Funktion implementiert"
git push -u origin feature/neue-funktion
# Pull Request erstellen, dann:
git checkout main
git pull
git branch -d feature/neue-funktion
Hotfix Workflow
git checkout main
git pull
git checkout -b hotfix/kritischer-bug
# ... Fix ...
git commit -am "Kritischen Bug behoben"
git checkout main
git merge hotfix/kritischer-bug
git tag -a v1.0.1 -m "Hotfix Release"
git push origin main --tags
git branch -d hotfix/kritischer-bug
Rebase vor Merge
git checkout feature-branch
git fetch origin
git rebase origin/main
# Konflikte lösen falls nötig
git push --force-with-lease
Tipps
- Commit oft: Kleine, fokussierte Commits sind besser als große.
- Aussagekräftige Nachrichten: Was wurde geändert und warum?
- Branches nutzen: Nie direkt auf main/master entwickeln.
- Vor Push prüfen:
git log origin/main..HEADzeigt ausstehende Commits. - Backup vor Reset: Bei
--hardgehen Änderungen verloren! - Force-Push vermeiden: Nur auf eigenen Feature-Branches.
Anleitung - Git über das Terminal nutzen
Was ist Git?
Git ist ein Versionskontrollsystem - ein Werkzeug, das jede Änderung an deinen Dateien festhält und es dir ermöglicht, mit anderen Menschen an demselben Projekt zu arbeiten, ohne dass ihr euch gegenseitig die Arbeit überschreibt. Du kannst es dir wie ein extrem detailliertes Tagebuch für deinen Code (oder beliebige andere Dateien) vorstellen, das jederzeit weiß, wer wann was geändert hat.
Schritt 1: Die Installation
Auf einem Debian- oder Ubuntu-System installierst du Git mit dem Paketmanager apt.
sudo apt update
sudo apt install git
Ob die Installation geklappt hat, prüfst du mit:
git --version
Schritt 2: Die einmalige Grundkonfiguration
Bevor du Git produktiv nutzen kannst, musst du dich ihm einmal vorstellen. Git speichert mit jedem Schnappschuss (jedem sogenannten Commit) den Namen und die E-Mail-Adresse der Person, die ihn erstellt hat - das ist später wichtig, wenn jemand verstehen will, wer welche Änderung gemacht hat. Diese Werte setzt du global, also für alle Projekte auf deinem Rechner, wie folgt:
git config --global user.name "Dein Name"
git config --global user.email "deine@email.de"
Das --global ist hier der entscheidende Teil: Es bedeutet, dass diese Einstellungen in deinem Benutzerprofil landen (genauer gesagt in der Datei ~/.gitconfig) und für jedes Projekt gelten, an dem du auf diesem System arbeitest. Du kannst die Werte jederzeit überschreiben, falls du in einem bestimmten Projekt mit einer anderen Identität arbeiten möchtest - dazu lässt du einfach das --global weg und führst den Befehl im Projektordner aus.
Schritt 3: Ein Projekt herunterladen (Klonen)
Der erste Schritt ist immer das Klonen: Du erstellst eine vollständige lokale Kopie des Projekts inklusive seiner gesamten Geschichte. Der Befehl dafür sieht so aus:
git clone https://git.beispiel.de/benutzername/projekt.git
Git legt dir daraufhin einen Ordner mit dem Namen des Projekts an, lädt alle Dateien herunter und versetzt diesen Ordner gleich in einen Zustand, in dem Git ihn überwacht. Wechsel mit cd projekt in das Verzeichnis.
Ein nützliches Detail: Wenn du nicht klonst, sondern in einem bestehenden Ordner ein neues Git-Projekt anlegen willst, nutzt du stattdessen git init. Das Klonen ist aber der typische Weg, wenn du an etwas Vorhandenem mitarbeitest.
Schritt 4: Den aktuellen Stand abholen (Pullen)
Sobald du das Projekt geklont hast, kann es passieren, dass jemand anderes Änderungen vornimmt, während du etwas anderes tust. Bevor du deine eigene Arbeit weitermachst - und ganz besonders bevor du deine Änderungen hochlädst - solltest du daher den aktuellen Stand vom Server holen. Das geschieht mit:
git pull
Hinter diesem schlichten Befehl stecken eigentlich zwei Schritte: Git lädt zunächst die neuesten Änderungen vom Server herunter (fetch) und führt sie dann mit deinem lokalen Stand zusammen (merge). Solange ihr nicht dieselben Zeilen in derselben Datei bearbeitet habt, läuft das geräuschlos durch. Tut ihr es doch, meldet Git einen Konflikt, den du manuell auflösen musst - aber das ist ein eigenes Thema, das wir uns merken können.
Schritt 5: Eigene Änderungen hochladen (Pushen)
Jetzt der spannende Teil: Du hast eine Datei geändert oder eine neue erstellt, und diese Änderung soll auf den Server. Dieser Vorgang besteht aus drei Schritten, und es lohnt sich, sie wirklich zu verstehen, weil viele Anfänger sie zusammenwerfen.
Im ersten Schritt sagst du Git, welche deiner Änderungen du im nächsten Schnappschuss festhalten willst. Das nennt sich staging:
git add datei.txt
Wenn du alle geänderten Dateien auf einmal vormerken willst, schreibst du git add . - der Punkt steht für „alles im aktuellen Verzeichnis und darunter".
Im zweiten Schritt erstellst du den eigentlichen Schnappschuss, den Commit, und gibst ihm eine Nachricht mit, die beschreibt, was du geändert hast:
git commit -m "Tippfehler in der Anleitung korrigiert"
Dieser Commit existiert nun zunächst nur lokal auf deinem Rechner. Erst der dritte Schritt schickt ihn auf den Server, wo andere ihn sehen können:
git push
Diese Trennung zwischen lokalem Festhalten und Hochladen ist eine der größten Stärken von Git: Du kannst auch ohne Internet arbeiten, mehrere Commits hintereinander machen und sie erst später gesammelt pushen.
Schritt 6: Den Login dauerhaft speichern
Standardmäßig fragt Git dich bei jedem Pull und Push nach Benutzername und Passwort, wenn du HTTPS-URLs verwendest. Es gibt zwei sinnvolle Wege, das zu beheben, und ein dritter Weg, der noch besser ist.
Variante A: Der Credential-Helper „store"
Die einfachste Lösung ist Git zu sagen, dass es deine Zugangsdaten in einer Datei speichern soll. Das geschieht mit einem einzigen Befehl:
git config --global credential.helper store
Beim nächsten Pull oder Push fragt Git dich noch ein letztes Mal nach Benutzername und Passwort - und merkt sich beides danach in der Datei ~/.git-credentials. Du wirst nie wieder gefragt. Der Haken: Die Datei liegt im Klartext auf deiner Festplatte. Auf einem persönlichen Arbeitsplatzrechner mit verschlüsseltem Heimverzeichnis ist das vertretbar; auf einem Server, den sich mehrere Leute teilen, eher nicht.
Variante B: Der Credential-Helper „cache"
Wenn du nicht magst, dass deine Zugangsdaten dauerhaft auf der Platte liegen, kannst du sie stattdessen für eine bestimmte Zeit im Arbeitsspeicher zwischenspeichern lassen:
git config --global credential.helper "cache --timeout=28800"
Der Wert 28800 sind Sekunden, also genau acht Stunden - ein praktischer Arbeitstag. Nach Ablauf dieser Zeit fragt Git wieder einmal nach. Das ist ein vernünftiger Kompromiss zwischen Bequemlichkeit und Sicherheit, kostet dich aber jeden Tag einmal eine Eingabe.
Variante C: SSH-Schlüssel (die elegante Lösung)
Wenn du langfristig mit Git arbeitest, lohnt sich der Umstieg auf SSH. Statt eines Passworts nutzt du ein kryptografisches Schlüsselpaar: einen privaten Schlüssel, der auf deinem Rechner bleibt, und einen öffentlichen, den du beim Server hinterlegst. Die beiden erkennen sich gegenseitig automatisch, und du wirst nie mehr nach einem Passwort gefragt.
Erzeugen tust du das Schlüsselpaar mit:
ssh-keygen -t ed25519 -C "deine@email.de"
Drücke bei den Rückfragen einfach Enter, um die Standardwerte zu akzeptieren. Den öffentlichen Schlüssel zeigst du dir dann an mit:
cat ~/.ssh/id_ed25519.pub
Diesen Text kopierst du und fügst ihn auf deinem Git-Server (Gitea, GitHub, GitLab) in den Einstellungen unter „SSH Keys" ein. Anschließend musst du nur noch dafür sorgen, dass du SSH-URLs statt HTTPS-URLs verwendest - sie beginnen mit git@ statt https://. Bei einem bestehenden Klon kannst du die URL umstellen mit:
git remote set-url origin git@git.beispiel.de:benutzername/projekt.git
Ab diesem Moment funktionieren git pull und git push ohne jede Passworteingabe und gleichzeitig deutlich sicherer als mit gespeichertem Passwort. Wenn dir dein Setup wichtig ist, ist das der Weg, den ich dir wärmstens ans Herz legen würde.
Eine kleine Zusammenfassung als Denkmodell
Wenn du den Ablauf einmal verinnerlicht hast, läuft jeder Arbeitstag im Grunde nach demselben Muster ab: Du holst dir mit git pull den aktuellen Stand, du arbeitest an deinen Dateien, du markierst die Änderungen mit git add, du hältst sie mit git commit -m "Beschreibung" fest, und du lädst sie mit git push hoch. Alles andere - Branches, Merges, Rebases, Tags - baut auf genau diesen Grundbefehlen auf. Wer diese fünf Schritte beherrscht, hat den weitaus größten Teil der täglichen Git-Arbeit bereits abgedeckt.
Erstellt: 04 Februar 2026