ToolActToolAct

Git-Befehlsreferenz

Komplettes Git-Befehle Referenzhandbuch, nach Kategorien organisiert

Alle: 65 个命令

Grundlegende Befehle(13)

git init

Neues Git-Repository im aktuellen Verzeichnis erstellen

git clone <url>

Remote-Repository lokal klonen

git clone --depth=1 <url>

Shallow Clone, nur letzter Commit

git add <file>

Datei zum Staging-Bereich hinzufügen

git add .

Alle Änderungen zum Staging hinzufügen

git commit -m "message"

Staged Änderungen committen

git commit --amend

Letzten Commit ändern

git status

Aktuellen Repository-Status anzeigen

git diff

Unstaged Änderungen anzeigen

git diff --staged

Staged Änderungen anzeigen

git config --list

Alle Konfiguration anzeigen

git config --global user.name "name"

Globalen Benutzername setzen

git config --global user.email "email"

Globale Email setzen

Branch-Management(14)

git branch

Alle lokalen Branches auflisten

git branch -a

Alle Branches (inklusive Remote) auflisten

git branch <name>

Neuen Branch erstellen

git branch -d <name>

Branch löschen

git branch -m <old> <new>

Branch umbenennen

git checkout <branch>

Zu Branch wechseln

git checkout -b <branch>

Neuen Branch erstellen und wechseln

git switch <branch>

Zu Branch wechseln (Git 2.23+)

git switch -c <branch>

Neuen Branch erstellen und wechseln (Git 2.23+)

git merge <branch>

Angegebenen Branch in aktuellen mergen

git merge --no-ff <branch>

Merge mit Merge-Commit

git rebase <branch>

Aktuellen Branch auf angegebenen Branch rebasen

git rebase --continue

Rebase nach Konfliktlösung fortsetzen

git cherry-pick <commit>

Spezifischen Commit auf aktuellen Branch anwenden

Remote-Operationen(10)

git remote -v

Remote-Repository Details anzeigen

git remote add <name> <url>

Remote-Repository hinzufügen

git fetch <remote>

Letzte Inhalte von Remote abrufen

git fetch --all

Updates von allen Remotes abrufen

git pull <remote> <branch>

Remote-Branch abrufen und mergen

git pull --rebase

Abrufen und rebase

git push <remote> <branch>

Zu Remote-Repository pushen

git push -f

Force Push (mit Vorsicht verwenden)

git push -u origin <branch>

Push und Upstream-Branch setzen

git push origin --delete <branch>

Remote-Branch löschen

Änderungen Rückgängig(8)

git reset <file>

Datei unstagen

git reset --soft HEAD~1

Letzten Commit zurücknehmen, Änderungen behalten

git reset --mixed HEAD~1

Commit und Staging zurücknehmen, Working Directory behalten

git reset --hard HEAD~1

Commit zurücknehmen, alle Änderungen verwerfen

git revert <commit>

Commit zurücknehmen (neuer Commit erstellt)

git restore <file>

Working Directory Datei wiederherstellen (Git 2.23+)

git restore --staged <file>

Datei unstagen (Git 2.23+)

git clean -fd

Ungetrackte Dateien und Verzeichnisse entfernen

Tag-Management(6)

git tag

Alle Tags auflisten

git tag <name>

Lightweight Tag erstellen

git tag -a <name> -m "msg"

Annotated Tag erstellen

git tag -d <name>

Lokalen Tag löschen

git push origin <tag>

Tag zu Remote pushen

git push --tags

Alle Tags zu Remote pushen

Historie Anzeigen(7)

git log

Commit-Historie anzeigen

git log --oneline

Kompakte Commit-Historie anzeigen

git log --oneline --graph --all

Alle Branch-Historie als Graph anzeigen

git show <commit>

Commit-Details anzeigen

git blame <file>

Änderungshistorie für jede Zeile anzeigen

git reflog

Alle Operationshistorie anzeigen

git bisect start

Binäre Suche für Problem-Commit starten

Stash(7)

git stash

Aktuelle Änderungen stashen

git stash save "message"

Änderungen mit Nachricht stashen

git stash list

Alle Stashes auflisten

git stash pop

Letzten Stash anwenden und löschen

git stash apply

Stash anwenden ohne Löschen

git stash drop

Letzten Stash löschen

git stash clear

Alle Stashes löschen

Was ist Git?

Ein Git-Cheat-Sheet ist eine schnelle Referenz für häufige Versionskontrollbefehle, sortiert nach der Aufgabe, die erledigt werden soll. Git ist ein verteiltes Versionskontrollsystem: Jeder Clone enthält die Projektgeschichte, Branches sind leichte Zeiger und Commits dokumentieren, wie sich eine Codebasis im Laufe der Zeit verändert hat. Das Cheat-Sheet hilft, wenn der Arbeitsablauf klar ist, aber die genaue Syntax fehlt, etwa beim Anzeigen gestagter Änderungen, Erstellen eines Branches, Rückgängigmachen eines Commits, Stashen, Taggen eines Releases oder Synchronisieren mit einem Remote. Es ist eine Referenz, kein Ersatz für Verständnis des Repository-Zustands. Destruktive Befehle wie reset --hard, clean -fd, rebase und force push sollten nur nach Prüfung von uncommitted Work, aktuellem Branch und Remote-Auswirkungen kopiert werden.

Verwendungshandbuch

Schnellreferenz

  1. Klicke auf eine Befehlskarte, um den Befehl zu kopieren
  2. Verwende die Suchleiste, um schnell bestimmte Befehle zu finden
  3. Klicke auf Kategorietags, um nach Typ zu filtern
  4. Fahre mit der Maus über Befehle, um detaillierte Beschreibungen anzuzeigen

Funktionen

Nach Szenarien sortiertBefehle sind nach Grundlagen, Branch, Remote, Undo, Tags, Verlauf und Stash gruppiert – so findest du alles schnell, ohne durch die gesamte Liste scrollen zu müssen.
Suche und FilterKombiniere die Suchleiste mit Kategoriefiltern, um Ergebnisse schnell einzugrenzen – perfekt, wenn du dich nur an Teile des Befehls oder der Beschreibung erinnerst.
Zum Kopieren anklickenKlicke auf die Befehlskarte zum Kopieren und passe dann bei Bedarf Branch-Namen, Dateipfade oder Commit-Hashes an.
RisikohinweisPrüfe bei Undo, Reset und Force Push den Wirkungsbereich, um nicht versehentlich lokale Änderungen zu löschen oder die gemeinsam genutzte Historie umzuschreiben.

Erweiterte Tipps

  • Verwende git restore --staged, um Dateien aus dem Staging-Bereich zu entfernen
  • Verwende git commit --amend, um den letzten Commit zu ändern
  • Verwende git stash, um Arbeitsfortschritt vorübergehend zu sichern
  • Verwende git revert, um gepushte Commits rückgängig zu machen

Anwendungsfälle

Die passende Befehlskategorie mitten in der Arbeit findenGit-Befehle nach Grundlagen, Branches, Remotes, Undo, Tags, Historie und Stash durchsuchen oder filtern – die richtige Syntax ist sichtbar, ohne einen langen Artikel zu scannen oder ein Tutorial-Fenster erneut zu öffnen. Jede Karte zeigt bereits die Kurzbeschreibung neben dem Befehl, was praktisch ist, wenn der Arbeitsablauf klar ist, aber die genauen Flags fehlen – etwa --force-with-lease versus --force, oder der Unterschied zwischen git restore und git reset.
Befehle mit Platzhaltern kopierenEin-Klick-Kopie für Befehle wie git checkout -b <branch>, git push -u origin <branch>, git log --oneline --graph --all oder git restore --staged <file> nutzen, dann Platzhalter in der eigenen Shell ersetzen. Da die Referenz im Browser lebt und keine Commit-Daten oder Branch-Namen irgendwohin gesendet werden, ist das Kopieren neben echten Hashes, internen Branch-Präfixen oder noch nicht gepushten Feature-Namen sicher.
Riskante Befehle vor der Ausführung prüfenDer Undo-Bereich fasst reset-, clean-, restore- und Force-Push-Workflows zusammen, sodass die zerstörerische Absicht auf einen Blick sichtbar ist. Vor git reset --hard HEAD~3 oder git push --force den aktuellen Branch mit git status und den Remote-Tracking-Status mit git rev-parse --abbrev-ref --symbolic-full-name @{u} prüfen – das Umschreiben gemeinsam genutzter Historie lässt sich von Teammitgliedern nicht rückgängig machen.
Branch-, Tag- und Stash-Snippets als Vorlagen speichernBefehle wie 'git switch -c feature/x', 'git tag -a v1.2 -m' und 'git stash push -m' wiederholen sich über Projekte hinweg mit den Branching- oder Release-Konventionen des Teams. Sie einmal in die Onboarding-Dokumentation, das Runbook oder die Pre-Commit-Hook-Konfiguration des Teams kopieren und bei Verhaltensänderungen von Git erneut prüfen – etwa wenn ein Projekt --force-with-lease statt einfach --force auf geschützten Branches verlangt.
Historie-Befehle nutzen, um das Repo zu lesen, nicht umzuschreiben'git log --oneline --graph --all', 'git blame -L' und 'git diff <branch>...' ausführen, um zu verstehen, wer was geändert hat, bevor ein Rebase oder Revert gestartet wird. Zuerst lesen ist billiger als die Wiederherstellung nach einer misslungenen Historienumschreibung – insbesondere in Monorepos, wo ein unbeabsichtigter Rebase über Feature-Branches Dutzende laufender Pull Requests ungültig machen kann.

Technisches Prinzip

Git speichert jeden Projektzustand als inhaltsadressierten Objektgraphen in .git/objects, wobei die Adresse ein 40-stelliger SHA-1-Hash ist (SHA-256 ist seit Git 2.29 als experimentelles Objektformat optional). Es gibt vier Objekttypen: blob enthält rohe Dateibytes, tree bildet Namen auf Blobs und Unterbäume ab, commit zeigt auf einen Tree plus Eltern-Commits und Autoren-Metadaten, und tag ist ein signierter Verweis auf eines der genannten Objekte. Branches und Tags unter refs/heads/, refs/remotes/ und refs/tags/ sind nur Textdateien, die einen SHA enthalten, und HEAD ist eine symbolische Referenz, die den aktuellen Branch benennt.

Lokale Änderungen fließen durch drei Bereiche: das Arbeitsverzeichnis, den Index (auch Staging-Bereich genannt, gespeichert in .git/index) und die Objektdatenbank. git add protokolliert Blob-Hashes im Index, git commit friert den Index in einen neuen Tree- plus Commit-Objekt ein, und git checkout/switch aktualisiert den Index und den Working Tree auf einen Ziel-Commit. Merges fallen in zwei Kategorien: Fast-Forward rückt den Branch-Zeiger einfach vor, wenn das Ziel ein direkter Nachfahre ist, während Drei-Wege-Merges (recursive- oder ort-Strategie) einen gemeinsamen Vorfahren berechnen und einen Merge-Commit mit zwei Elternteilen erstellen. git rebase schreibt die Historie um, indem Commits einzeln auf eine neue Basis repliziert werden und dabei neue SHAs entstehen.

Die Remote-Synchronisierung erfolgt über das HTTPS-Smart-Protokoll, SSH oder das veraltete git://-Protokoll und tauscht Pack-Dateien aus, die durch Delta-Kompression erzeugt werden. Nach einem Fetch speichert Git den Snapshot unter refs/remotes/origin/* und der Reflog unter .git/logs/ führt standardmäßig eine 90-tägige Undo-Spur (gc.reflogExpire), sodass selbst reset --hard oder ein missglückter Rebase wiederhergestellt werden können, bevor die Garbage Collection nicht erreichbare Objekte bereinigt.
  • Objektmodell: blob, tree, commit, tag – inhaltsadressiert über SHA-1 (oder SHA-256 seit 2.29), gespeichert als lose Objekte unter .git/objects/xx/ oder gepackt in .git/objects/pack/*.pack
  • Index/Staging: .git/index ist eine Binärdatei, die Pfad → Blob-Hash + Stat-Info abbildet; git add aktualisiert sie, git commit friert sie in einen Tree ein
  • Refs und HEAD: refs/heads/<branch>, refs/remotes/<remote>/<branch>, refs/tags/<tag> sind einfache Dateien mit einem SHA; HEAD ist eine symbolische Referenz auf den aktuellen Branch
  • Merge-Strategien: Fast-Forward, wenn das Ziel ein Nachfahre ist, sonst Drei-Wege-Recursive/ort-Merge mit der Merge-Basis; --no-ff erzwingt einen Merge-Commit
  • Rebase-Umschreibungen: git rebase repliziert Commits auf eine neue Basis und erzeugt neue SHAs, was gemeinsame Historie bricht, wenn gepusht – daher wird --force-with-lease gegenüber --force bevorzugt
  • Reflog-Wiederherstellung: .git/logs/HEAD und Ref-spezifische Logs bewegen Ref-Bewegungen für 90 Tage (gc.reflogExpire); git reflog plus git reset stellt nach destruktiven Operationen wieder her
  • Transport: Smart HTTPS, SSH oder git:// verhandeln Pack-Dateien über das upload-pack/receive-pack-Protokoll; Shallow Clones verwenden --depth zur Begrenzung der Historie

Beispiele

Neuen Branch erstellen und wechseln

git checkout -b feature/login  # Neuen Branch erstellen und wechseln

Änderungen im Arbeitsverzeichnis rückgängig machen

git restore filename  # Datei auf den letzten committeten Stand zurücksetzen

Commit-Verlauf anzeigen

git log --oneline --graph --all  # Verlauf aller Branches grafisch darstellen

FAQ

Wie mache ich meinen letzten Commit rückgängig?

git reset --soft HEAD~1 lässt deine Änderungen gestaged, sodass du erneut committen kannst; git reset --mixed HEAD~1 behält sie im Working Tree, aber unstaged; git reset --hard HEAD~1 verwirft sie. Wenn der Commit bereits gepusht ist, nutze stattdessen git revert HEAD — das erzeugt einen neuen Commit, der die Änderung rückgängig macht, ohne die History umzuschreiben.

Was ist der Unterschied zwischen git pull und git fetch?

git fetch lädt nur Commits vom Remote in deine lokalen Refs herunter — dein Working Branch wird nie angefasst. git pull entspricht git fetch gefolgt von git merge (oder git rebase, falls --rebase gesetzt ist). Nutze fetch, wenn du Upstream-Änderungen vor der Integration prüfen willst.

Wie verwerfe ich lokale Änderungen an einer Datei?

git restore <file> verwirft uncommittete Änderungen im Working Tree; git restore --staged <file> macht ein Staging rückgängig, ohne den Inhalt zu verlieren; git checkout HEAD -- <file> stellt die Version aus dem letzten Commit wieder her. Für unverfolgte Dateien nutze git clean -f oder -fd, um auch Verzeichnisse zu entfernen.

Wann sollte ich rebase vs. merge nutzen?

Rebase, wenn du auf einem privaten Feature-Branch eine lineare History willst, bevor du ihn zurückmergest. Merge, wenn du einen geteilten Branch integrierst und die tatsächliche Entwicklungshistorie erhalten bleiben soll. Rebase niemals Commits, die auf einen geteilten Branch gepusht wurden, sofern das Team nicht zustimmt — es schreibt SHAs um und zerstört Klone anderer.

Wie sehe ich, was als Nächstes gepusht wird?

git log @{u}.. zeigt Commits auf deinem Branch, die nicht im Upstream sind. git diff @{u} zeigt das kombinierte Diff. git status (nach einem fetch) im Vergleich zu origin zeigt Ahead-/Behind-Zähler.

Wie stelle ich einen gelöschten Branch oder verlorenen Commit wieder her?

git reflog listet jede Position, an der HEAD je war; finde die SHA des verlorenen Commits und führe git checkout <sha> oder git branch <name> <sha> aus. Reflog-Einträge halten standardmäßig etwa 90 Tage vor der Garbage Collection — also kümmere dich kurz nach dem Fehler darum.

Wie ändere ich einen Commit am sichersten nachträglich?

git commit --amend lässt dich die Nachricht des letzten Commits bearbeiten oder vergessene Dateien hinzufügen. Es schreibt die SHA um, also tu es nur mit lokalen, noch nicht gepushten Commits. Musst du einen gepushten Commit ändern, pushe mit --force-with-lease (nicht --force), um Updates der Teammitglieder nicht zu überschreiben.

Verwandte Tools

HTTP-Statuscode-Abfrage

Kostenlose Online-HTTP-Statuscode-Referenz mit allen Standardcodes. Suche und Filterung nach Kategorie, schnell Bedeutungen von 1xx bis 5xx finden.

MIME-Typen Referenz

Kostenloses Online-MIME-Typen-Suchtool. Schnell MIME-Typen für Dateiendungen finden. Suche und Filterung nach Kategorie, deckt Dokumente, Bilder, Audio, Video und mehr ab.

ASCII-Tabellenabfrage

Kostenlose Online-ASCII-Tabelle mit Steuerzeichen, druckbaren Zeichen und erweiterten Zeichen. Suche und Filterung nach Kategorie für schnelle Zeichencode-Suche.

Cron-Ausdruck-Generator

Kostenloses Online-Cron-Ausdruck-Tool zum Parsen und Generieren von Cron-Zeitplan-Ausdrücken. Visuelle Konfiguration, Sekundenebene, Quartz erweiterte Syntax unterstützen.

IP-Adressabfragetool

Kostenloses Online-IP-Adressen-Abfrage-Tool. Sofort Ihre öffentliche IP-Adresse und Geolokalisierungs-Info einschließlich Land, Stadt und ISP finden.

Markdown-Editor

Kostenloser Online-Markdown-Editor mit Echtzeitvorschau, Syntaxhervorhebung & HTML-Export. Tabellen, Codeblöcke, Diagramme unterstützen, effizienter schreiben.