Die Git-Befehlsübersicht ist eine Tabelle für den direkten Einsatz: 149 Befehle, gruppiert in elf Szenarien – Einrichtung und Konfiguration, tägliches Committen, Branches, Mergen und Rebasen, Zurücknehmen und Verwerfen, Zusammenarbeit über Remotes, Stash, Tags, Submodule und Worktrees, Historie und Fehlersuche sowie Ignorieren und Attribute. Jeder Eintrag liefert eine Erklärung, ein direkt einfügbares Beispiel und eine zweistufige Risikomarkierung „Achtung / Gefahr“ – Befehle, die nicht committete Änderungen verwerfen oder gemeinsam genutzte Historie umschreiben, fallen sofort auf.
Die Git-Befehlsübersicht ist eine Tabelle für den direkten Einsatz: 149 Befehle, gruppiert in elf Szenarien – Einrichtung und Konfiguration, tägliches Committen, Branches, Mergen und Rebasen, Zurücknehmen und Verwerfen, Zusammenarbeit über Remotes, Stash, Tags, Submodule und Worktrees, Historie und Fehlersuche sowie Ignorieren und Attribute. Jeder Eintrag liefert eine Erklärung, ein direkt einfügbares Beispiel und eine zweistufige Risikomarkierung „Achtung / Gefahr“ – Befehle, die nicht committete Änderungen verwerfen oder gemeinsam genutzte Historie umschreiben, fallen sofort auf.
Sie ist für drei Momente gedacht: Du weißt noch, was du tun willst, aber nicht mehr, wie der Befehl geschrieben wird (Suche nach „Commit rückgängig“, „Remote-Branch löschen“); du kennst den Befehl, bist aber unsicher, ob er etwas verlieren kann (Risikostufe und Hinweise lesen); oder du hast zum ersten Mal mit Git zu tun und willst verstehen, was add, commit und push eigentlich hin- und herschieben (die Grafik der vier Bereiche oben und die Ablaufskizzen darunter ansehen).
Unten auf der Seite wartet ein reiner In-Memory-Git-Terminal-Simulator: Er beherrscht über 30 gängige Unterbefehle, das Commit-Diagramm rechts verändert sich live mit jedem Befehl, und 10 Übungslevel führen vom „ersten Commit“ bis zum „Merge-Konflikt lösen“. Er ist kein echtes Git und greift weder auf deinen Rechner noch auf das Netzwerk zu, die Semantik folgt aber dem offiziellen Handbuch – das Geübte lässt sich direkt auf eine echte Maschine übertragen.
Bedienung
01Suchenoben den Befehlsnamen oder dein Vorhaben eintippen (etwa „zurücknehmen“, „Force-Push“, „Branch löschen“); mehrere Wörter werden durch Leerzeichen getrennt und müssen alle treffen; die Treffer bleiben in ihrer Gruppe.
02Nach Szenario stöbernauf ein Gruppen-Chip klicken, um nur eine Kategorie zu sehen, oder über das Gruppenverzeichnis unter „Die vier Bereiche“ an die passende Stelle springen; mit „nur riskante Befehle“ vor dem Ausführen schnell gegenprüfen.
03Kopierenauf den blauen Befehlstext oder das Kopiersymbol rechts klicken, um den Befehl zu kopieren; das zweite Symbol kopiert das Beispiel; unter „Häufige Kombinationen“ lässt sich ein ganzes Rezept am Stück kopieren.
04Favoritender Stern heftet häufig genutzte Befehle an „Meine Favoriten“ oben auf der Seite; gespeichert wird im Browser (localStorage), ein Gerätewechsel synchronisiert nicht.
05Übenzum Übungsterminal scrollen, ein Level wählen und auf das Ziel hin Befehle tippen; jeder Befehl wird automatisch geprüft, bei Stocken hilft „Tipp“ oder „Musterlösung“, „Zurücksetzen“ bringt das Level in den Ausgangszustand.
Ein- und Ausgabebeispiele
Im Suchfeld „Commit rückgängig“ eintippen – aus der Gruppe „Zurücknehmen und Verwerfen“ erscheinen diese Einträge (Auszug):
Level 4, „letzten Commit zurücknehmen und Änderungen behalten“, im Simulator:
text
git reset --soft HEAD~1 letzten Commit zurücknehmen, Änderungen bleiben bereitgestellt Achtung
git reset HEAD~1 letzten Commit zurücknehmen, Änderungen wandern ungestaged in den Arbeitsbereich
git reset --hard <commit> Branch-Zeiger, Index und Arbeitsbereich komplett auf commit zurücksetzen Gefahr
git revert <commit> erzeugt einen neuen Commit, der die Änderung aufhebt; Historie bleibt, gefahrlos pushbar
bash
user@toolun-lab:~/project (main)$ git log --oneline
7f3a1c2 (HEAD -> main) wip: unordentlicher Commit
2b9e0d4 init: add README
user@toolun-lab:~/project (main)$ git reset --soft HEAD~1
HEAD ist jetzt bei 2b9e0d4 init: add README
--soft: verschiebt nur den Branch-Zeiger, Index und Arbeitsbereich bleiben erhalten (der Inhalt des zurückgenommenen Commits liegt bereitgestellt vor)
Tipp: Der verworfene Commit 7f3a1c2 lässt sich weiterhin mit git reflog zurückholen
user@toolun-lab:~/project (main)$ git status -s
A app.js
A secret.env
✔ Geschafft: letzten Commit zurücknehmen, aber die Änderungen behalten.
Funktionsweise
Die vier Bereiche: Befehle verschieben nur Daten
Fast jeder Git-Befehl lässt sich als „Inhalt von einem Bereich in einen anderen bewegen“ lesen. Der Arbeitsbereich (Working Tree) sind die Dateien, die du siehst und bearbeitest; der Index (Staging-Bereich) ist die Liste, die festhält, wie der nächste Commit aussehen wird; das lokale Repository (.git) speichert alle Commits; das Remote-Repository ist dasselbe auf einer anderen Maschine.
add legt in den Index, commit ins Repository, push nach remote; zurück geht es mit fetch und restore
Mit diesem Bild haben viele „Wie nehme ich das zurück?“-Fragen eine einheitliche Antwort: falsch geändert, aber noch nicht add – mit git restore <file> aus dem Index zurückholen; hinzugefügt, aber nicht committen wollen – git restore --staged; committet und rückgängig machen – git reset; bereits gepusht – nur git revert mit einem zusätzlichen Gegen-Commit ist sicher.
Commits sind Momentaufnahmen, Branches nur Zeiger
Ein Commit-Objekt hält eine Momentaufnahme des gesamten Verzeichnisbaums (keinen Diff), die IDs der Eltern-Commits, Autor und Zeitstempel sowie die Nachricht. All das wird mit SHA-1 (neue Repositories optional SHA-256) zur Commit-ID gehasht – jede Änderung, und sei es ein einzelnes Zeichen in der Nachricht, ergibt eine völlig neue ID. Deshalb „schreiben“ --amend, rebase und cherry-pick die Historie um: Sie erzeugen neue Commits, die alten werden nur nicht mehr referenziert.
Ein Branch ist eine 40-stellige Datei unter .git/refs/heads/<name>, deren Inhalt die ID eines Commits ist. HEAD zeigt normalerweise auf einen Branchnamen. Einen Branch anzulegen geht daher sofort (eine kleine Datei wird geschrieben), ein Branchwechsel hängt HEAD auf einen anderen Namen um und aktualisiert den Arbeitsbereich auf die Momentaufnahme dieses Commits, und einen Branch zu löschen entfernt nur einen Zeiger – die Commits selbst verschwinden nicht sofort.
merge oder rebase – die Abwägung
Gleicher Ausgangspunkt, zwei Historien nach merge und rebase
merge hält getreu fest, was passiert ist: Die beiden Linien treffen sich im Merge-Commit, und jeder kann erkennen, dass das Feature parallel entwickelt wurde. rebase lässt die Historie aussehen, als wäre sie immer linear gewesen – git log liest sich besser, git bisect lässt sich leichter nutzen –, aber alle Commit-IDs ändern sich. Faustregel: Eigene, noch nicht gepushte Branches ruhig rebasen; alles, worauf andere aufbauen könnten, nur mergen. git pull --rebase ist die tägliche Anwendung: die paar lokalen, nicht gepushten Commits auf den neuesten Remote-Stand heben und eine Reihe von „Merge branch 'main' of …“-Commits vermeiden.
Die drei Modi von reset
Welcher Bereich in welchem Modus auf den Ziel-Commit zurückgezogen wird
--soft passt zu „Commits aufteilen / zusammenfassen“: Der Zeiger geht zurück, der Inhalt bleibt im Index. --mixed (Standard) passt zu „neu auswählen, was committet wird“. --hard ist das echte Verwerfen: Nie committete Änderungen im Arbeitsbereich sind nicht mehr zu retten, die verworfenen Commits liegen dagegen weiterhin im Objektspeicher – git reflog zeigt jede Bewegung von HEAD, und git reset --hard HEAD@{1} bringt dich vor das Reset zurück. Standardmäßig hält das Reflog 90 Tage (unerreichbare Einträge 30 Tage) – das ist Gits Fenster für Reue.
Wie die Risikostufen zustande kommen
„Gefahr“ bekommen zwei Arten von Befehlen: solche, die nicht committete Inhalte im Arbeitsbereich verwerfen (restore, reset --hard, clean, stash drop, checkout -- <file>), und solche, die Historie umschreiben, die andere schon haben könnten (push --force, branch -D bei einem nicht gemergten Branch). „Achtung“ gilt für Befehle, die den Zustand rückholbar ändern oder deren Tragweite zuerst geklärt werden sollte (commit --amend, rebase, merge --squash, push --delete). Nur lesende Befehle (log, diff, status, show, blame) tragen keine Markierung.
Umfang und Grenzen
Befehlsquelle
Grundlage ist das offizielle Git-Handbuch (git-scm.com/docs, Git 2.4x); git switch / git restore erfordern Version 2.23 oder neuer, die ältere Schreibweise checkout ist mit aufgeführt.
Auswahlkriterien
Befehle und Optionen aus Entwicklung, Zusammenarbeit und Fehlersuche; jeder Eintrag lässt sich in einer Manpage nachschlagen. Plumbing-Befehle (hash-object, cat-file, update-ref usw.) und plattformspezifische Abläufe (Web-Oberflächen wie GitHub-PR oder GitLab-MR) fehlen bewusst.
Simulator
Er bildet die Kernsemantik gängiger Unterbefehle ab (Fast-Forward / Drei-Wege-Merge, Konflikterkennung pro Datei, die drei reset-Modi, lineares rebase, Stash, Remote-Push und -Pull); interaktives Rebase, bisect, Submodule, Hooks und sämtliche Optionen von Konfigurationsdateien werden nicht unterstützt, und ein Rebase mit Konflikt bricht automatisch ab, statt auf deine Lösung zu warten.
Was er nicht macht
keine Verbindung zu einem echten Repository, kein Lesen des .git auf deinem Rechner, kein grafischer Konfliktlöser.
Favoriten und Zuletzt verwendet
nur im lokalen Browser gespeichert; mit dem Löschen der Websitedaten sind sie weg.
Typische Anwendungsfälle
Zu früh committet, falsche Nachricht, falscher Branch
Nach „rückgängig“ suchen oder direkt die Gruppe „Zurücknehmen und Verwerfen“ öffnen, zuerst „noch nicht gepusht“ (reset / --amend) von „bereits gepusht“ (revert) trennen und dann den Befehl wählen. Unter „Häufige Kombinationen“ liegen komplette Rezepte wie „auf main committet, soll in einen neuen Branch“.
Vor dem Mergen aufräumen
git rebase -i HEAD~N zusammen mit squash / fixup / reword; die Rebase-Karte in der Grafik zeigt, wie aus einer Verzweigung eine gerade Linie wird und warum alte Commits grau werden.
Erste Zusammenarbeit: Remote, Tracking, abgelehnter Push
Die Gruppe „Zusammenarbeit über Remotes“ reicht von remote add bis push -u und --force-with-lease; Übungslevel 8 (Push) und 9 (gepushten Commit zurücknehmen) decken die zwei häufigsten „Push geht nicht“-Momente ab.
„Verschwundenes“ zurückholen
git reflog, git fsck --lost-found und git stash list stehen unter „Zurücknehmen und Verwerfen“ nebeneinander; das Rezept „gelöschten Branch wiederherstellen“ erledigt es in zwei Schritten.
FAQ
git reset oder git revert – was nehme ich?
Entscheidend ist, ob der Commit gepusht wurde. Nicht gepusht: reset zieht den Zeiger direkt zurück, die Historie bleibt sauber. Bereits gepusht: revert hängt einen Gegen-Commit an, ohne die Historie umzuschreiben, die andere schon haben; sonst läuft die nächste Person beim pull in eine Verzweigung.
Warum erscheinen nach git pull Commits wie „Merge branch 'main' of …“?
Weil lokal nicht gepushte Commits liegen und remote neue dazugekommen sind; ein Standard-pull führt beide Seiten per Merge zusammen. Vermeiden lässt sich das mit git pull --rebase oder einmalig git config --global pull.rebase true.
Was ist der Unterschied zwischen --force und --force-with-lease?
--force überschreibt den Remote-Branch bedingungslos. --force-with-lease prüft zuerst, ob der Remote-Branch noch der Commit ist, den du beim letzten Fetch gesehen hast, und verweigert den Push, wenn jemand anderes etwas Neues gepusht hat – das schützt vor dem Unfall „ich habe die Commits einer Kollegin überschrieben“. Nach dem Umschreiben der Historie immer die zweite Variante verwenden.
Warum sehen die Commit-IDs im Simulator immer gleich aus?
Echtes Git hasht Inhalt, Autor und Zeitstempel zusammen; der Simulator ersetzt die reale Zeit durch eine logische Uhr und rechnet deterministisch – dieselbe Befehlsfolge ergibt dieselben IDs, was den Vergleich mit der Musterlösung erleichtert. Sie weichen bewusst von dem ab, was echtes Git berechnen würde.
Funktionieren die Befehle aus der Übersicht unter Windows?
Die Befehle selbst sind plattformübergreifend identisch. Unterschiede macht die Shell: In PowerShell braucht && Version 7.x, Pfade gehören sicherheitshalber in Anführungszeichen, und für Zeilenumbrüche lohnt sich der Eintrag core.autocrlf aus „Einrichtung und Konfiguration“.
Datenschutz
Alles auf dieser Seite (Befehlstabelle, Skizzen, Simulator) ist statischer Inhalt, der mit der Seite ausgeliefert wird und lokal im Browser läuft; Suchen, Kopieren, Favoriten und Üben senden keine Anfragen an einen Server. Favoriten liegen im localStorage des Browsers und sind für die Website nicht auslesbar. Die externen Links führen zur offiziellen Git-Dokumentation und werden beim Klick von der jeweiligen Gegenseite verarbeitet.
Quellen und weiterführende Literatur
Git Reference Manual(abgerufen am 2026-09-09)– die maßgebliche Manpage zu jedem Befehl; alle Einträge dieser Seite wurden daran geprüft.
Pro Git, 2. Auflage (englische Ausgabe)(abgerufen am 2026-09-09)– Kapitel 3 „Branches“ und Abschnitt 7.7 „Reset Demystified“ sind der beste Einstieg in Zeiger und die drei Bereiche.
git-reset Manpage(abgerufen am 2026-09-09)– die offizielle Tabelle, wie die drei Modi HEAD, Index und Arbeitsbereich beeinflussen.
git-rebase Manpage(abgerufen am 2026-09-09)– der Abschnitt „Recovering from upstream rebase“ erklärt, warum gemeinsam genutzte Branches nicht rebased werden sollten.
149 Git-Befehle nach Anwendungsfall gruppiert, jeder mit Erklärung, Beispiel und Gefahrenstufe, durchsuchbar, per Klick kopierbar und als Favorit speicherbar; dazu Ablaufskizzen und ein Übungsterminal
Dieses Werkzeug ist noch nicht vollständig übersetzt; einige Inhalte nutzen die Ausgangssprache oder die Rückfallsprache.
Gesamt 149 Befehle
Daten fließen zwischen den vier Bereichen: add in den Staging-Bereich, commit ins lokale Repository, push zum Remote-Repository; in die andere Richtung geht es mit fetch / restore / switch. pull = fetch + merge.
Initialisierung und Konfiguration
14 Befehle· Neue Repositorys, Klone, Identitäten und gemeinsame Konfigurationen
Verwandeln Sie das aktuelle Verzeichnis in ein Git-Repository (generieren Sie .git/).
git init
git init -b main # Geben Sie den anfänglichen Zweignamen an
Klonen Sie das Remote-Repository lokal und konfigurieren Sie den Ursprung automatisch
Alle Änderungen vorübergehend speichern: neu, geändert, gelöscht (git add. Äquivalent in 2.x)
git add -A
git add -u # Es werden nur vorübergehende Änderungen und Löschungen der verfolgten Dateien gespeichert, neue Dateien ausgenommen.
Drücken Sie interaktiv auf »Blockieren«, um die Änderungen auszuwählen, die bereitgestellt werden sollen, und übertragen Sie nur einen Teil einer Datei
git add -p src/app.js
# y dieses Stück vorübergehend speichern n überspringen s in kleinere Stücke aufteilen q beenden
Machen Sie den Inhalt des Staging-Bereichs zu einer Übermittlung
git commit -m »fix: Korrekte Beurteilung des Login-Timeouts«
Hinzufügen überspringen: Geänderte Commits von verfolgten Dateien automatisch bereitstellen (neue Dateien werden nicht einbezogen)Achtung
git commit -am "docs: update readme"
Es ist leicht, Änderungen vorzunehmen, die Sie nicht übernehmen möchten. Führen Sie einfach »git status« aus, bevor Sie einen Commit durchführen.
Ersetzen Sie die neueste Einreichung durch den Inhalt des Staging-Bereichs + neue Beschreibung (Tippfehler korrigieren, fehlende Dateien ergänzen)Achtung
git add forgotten.js
git commit --amend --no-edit #Dateien hinzufügen, aber die Beschreibung nicht ändern
git commit --amend -m "neue Beschreibung"
Generieren Sie eine neue Einreichungs-ID. Ändern Sie keine Einsendungen, die bereits gepusht wurden, andernfalls müssen sie gepusht werden.
Erstellen Sie ein leeres Commit ohne Änderungen (CI auslösen, Knoten markieren)
Arbeitsbereich vs. Staging-Bereich: Es sind noch keine Änderungen hinzuzufügen
git diff
git diff src/app.js # Nur eine Datei anzeigen
Staging-Bereich vs. letztes Commit: einzureichender Inhalt (--cached Synonym)
git diff --staged
Vergleichen Sie die Unterschiede zwischen zwei Commits/Branches
git diff main feature
git diff HEAD~3 HEAD -- src/
git diff main...feature # Feature-Änderungen relativ zum Verzweigungspunkt
Schauen Sie sich nur die Statistiken an, wie viele Zeilen für jede Datei geändert wurden
git diff --stat HEAD~1
Zeigen Sie Unterschiede wortweise statt zeilenweise an, sodass Sie Änderungen beim Text leichter erkennen können
git diff --word-diff=color README.md
Commit-Verlauf anzeigen
git log
git log -5 # Letzte 5 Einträge
git log --oneline # Eine Zeile pro Zeile
Die Historie aller Branches wird als Diagramm mit Referenznamen dargestellt
git log --oneline --graph --all --decorate
Informationen und Änderungen zu einem Commit anzeigen
git show HEAD
git show a1b2c3d --stat
git show HEAD:src/app.js # Zeigen Sie den Dateiinhalt einer bestimmten Version an
Löschen Sie die Datei und legen Sie »delete« im temporären Speicherbereich ab
git rm old.txt
git rm -r legacy/
Nur lokale Dateien aus dem Repository entfernen und behalten (wird verwendet, wenn node_modules / .env versehentlich übermittelt wird)
git rm --cached .env
echo ".env" >> .gitignore
Dateien umbenennen/verschieben und bereitstellen (entspricht mv + git add)
Lokale Branches auflisten (* ist die aktuelle Branch)
git branch
git branch -a # schließt entfernte Branches ein
git branch -vv # Mit der neuesten Commit- und Tracking-Beziehung
Erstellen Sie beim aktuellen Commit einen Branch, ohne dorthin zu wechseln
git branch feature/login
git branch hotfix a1b2c3d # Aus dem angegebenen Commit erstellen
Wechseln Sie zu einem vorhandenen Branch (2.23+; alte Schreibweise von git checkout <branch>)
git switch main
git switch - # Gehe zurück zum vorherigen Branch
Erstellen Sie einen neuen Branch und wechseln Sie zu diesem (alte Schreibweise von git checkout -b)
git switch -c feature/search
git switch -c hotfix origin/main # Basierend auf dem Remote-Branch
Erstellen und wechseln (alte Schreibweise, in allen Versionen verfügbar)
git checkout -b release/1.2
Benennen Sie den Branch um (wenn Sie alt weglassen, wird der aktuelle Branch umbenannt)
git branch -m master main
git push -u origin main && git push origin --delete master
Zusammengeführte lokale Branches löschen (nicht zusammengeführte Branches werden abgelehnt)
git branch -d feature/login
Erzwingen Sie das Löschen lokaler Branches, unabhängig davon, ob sie zusammengeführt werden oder nichtGefahr
git branch -D experiment
Eindeutige Commits für den Branch werden zu Waisen und können kurzfristig mit Reflog abgerufen werden.
Listen Sie Branches auf, die mit dem aktuellen Branch zusammengeführt wurden (schauen Sie sich dies beim Bereinigen zuerst an)
git branch --merged main
git branch --no-merged # umgekehrt
Legen Sie den Upstream des aktuellen Zweigs auf einen Remote-Branch fest (es ist nicht erforderlich, Parameter für Pull/Push danach zu schreiben)
git branch -u origin/feature/login
Welche Branches enthalten diesen Commit?
git branch -a --contains a1b2c3d
Schauen Sie sich ein Commit an und geben Sie den Status »getrennter Kopfzeiger« ein. Verwenden Sie es nur, wenn Sie Änderungen vornehmen möchten.Achtung
git checkout v1.0
git switch -c fix-from-v1 # Wenn Sie die Änderungen beibehalten möchten, erstellen Sie hier einen Branch
Einsendungen in diesem Zustand gehören zu keinem Branch und gehen nach dem Ausschneiden leicht verloren.
Listen Sie die Branches nach der letzten Einreichungszeit sortiert auf, um herauszufinden, womit Sie in letzter Zeit beschäftigt waren
git branch --sort=-committerdate | head
Löschen Sie Referenzen auf entfernte Branches, die beim Ziehen nicht mehr vorhanden sind (beschneiden).
git fetch -p
git remote prune origin
Zusammenführen und umbasieren
16 Befehle· Merge/Rebase/Cherry-Pick und Konfliktbehandlung
Branch in den aktuellen Branch zusammenführen: Schneller Vorlauf, wenn möglich, andernfalls wird ein Zusammenführungs-Commit generiert
git switch main
git merge feature/login
Generieren Sie immer Zusammenführungs-Commits und behalten Sie dabei den Verlauf von »Hier gab es eine Verzweigung« bei.
git merge --no-ff feature/login
Komprimieren Sie alle Änderungen am Branch in einem temporären Speicher, und Sie können manuell einen Commit durchführen
Bei der Umbasierung werden die Bedeutungen von »unsere/ihre« umgekehrt: »unser« ist der Branch, der umbasiert wird.
»Verschieben« Sie die Commits des aktuellen Zweigs in die Basis und spielen Sie sie dann erneut ab, um den linearen Verlauf zu erhaltenAchtung
git switch feature
git rebase main
Alle verschobenen Commit-IDs ändern sich; Branches, die verschoben wurden und an denen jemand arbeitet, sollten nicht neu basiert werden.
Interaktives Rebase: Commits nach Commit zusammenführen/umschreiben/neu anordnen/löschenAchtung
git rebase -i HEAD~3
# auswählen, behalten, umformulieren, die Beschreibung ändern, quetschen, mit der vorherigen zusammenführen, korrigieren, zusammenführen und die Beschreibung verlieren, löschen, löschen
Rebase stößt auf einen Konflikt: Lösen Sie ihn und fahren Sie nach dem Hinzufügen fort
git add .
git rebase --continue
Geben Sie diese Umbasierung auf und kehren Sie dorthin zurück, wo Sie begonnen haben
git rebase --abort
Migrieren Sie die Commits von old-base..branch nach new-base
git rebase --onto main server client
Geeignet für den Fall, dass »die Branch am falschen Ort eröffnet wird«.
Erstellen Sie zuerst einen Fixup-Commit und führen Sie ihn beim Rebasing automatisch mit dem Ziel-Commit zusammen
git commit --fixup a1b2c3d
git rebase -i --autosquash a1b2c3d~1
Kopieren Sie die Änderungen eines bestimmten Commits in den aktuellen Branch (neue ID).
git cherry-pick a1b2c3d
git Cherry-pick a1b2c3d..e5f6g7h # Ein Bereich (außer a1b2c3d)
Änderungen nur auf den Arbeitsbereich und den Staging-Bereich anwenden, nicht automatisch festschreiben
git cherry-pick -n a1b2c3d
Lösen Sie Konflikte nacheinander mit konfigurierten grafischen Tools
Denken Sie an die Konfliktlösungsmethode und verwenden Sie beim nächsten Mal automatisch denselben Konflikt wieder
Rollback und Rückgängig machen
16 Befehle· Arbeitsbereich/Staging-Bereich/Übermittlung rückgängig machen und verlorene Inhalte wiederherstellen
Verwerfen Sie die Änderungen am Arbeitsbereich und stellen Sie die Staging-Area-Version wieder her (alte Schreibweise von git checkout – <file>).Gefahr
Machen Sie das letzte Commit rückgängig und geben Sie die Änderungen ohne Bereitstellung an den Arbeitsbereich zurück (Standard: --mixed).
git reset HEAD~1
Der Verzweigungszeiger, der temporäre Speicherbereich und der Arbeitsbereich werden alle zum Festschreiben zurückgegeben, und nicht festgeschriebene Änderungen werden verworfen.Gefahr
git reset --hard HEAD~1 # Den letzten Commit wegwerfen
git reset --hard origin/main # Genau das Gleiche wie remote
Änderungen am Arbeitsbereich sind irreversibel; Festgeschriebene können mit git reflog abgerufen werden.
Verschieben Sie eine Datei aus dem Staging-Bereich (behalten Sie den Arbeitsbereich bei), was der Wiederherstellung von --staged entspricht
git reset package-lock.json
Generieren Sie einen neuen Commit, um die Commit-Änderungen auszugleichen. Der Verlauf bleibt unverändert und kann sicher übertragen werden
git revert HEAD
git revert a1b2c3d --no-edit
Machen Sie einen Teil der Übermittlungen stapelweise rückgängig und übermitteln Sie sie am Ende zusammen
Eine Zusammenführung rückgängig machen (-m 1 bedeutet, die Seite des ersten übergeordneten Commits beizubehalten)Achtung
git revert -m 1 f00ba12
Nachdem Sie die Zusammenführung rückgängig gemacht haben, müssen Sie diese Wiederherstellung rückgängig machen, bevor Sie sie im selben Branch zusammenführen.
HEAD-Verschiebungsdatensatz: Zurücksetzen/Rebase/Abrufen »verschwundener« Commits nach dem Löschen von Branches
git reflog
git reset --hard HEAD@{2} # Rückkehr zum Zustand vor Schritt 2
git branch Rescue a1b2c3d # Erstellen Sie einen Branch für die verwaiste Übermittlung
Alle nicht verfolgten Dateien und Verzeichnisse löschen (Vorschau zuerst mit -n anzeigen)Gefahr
git clean -n # Vorschau dessen, was gelöscht werden soll
git clean -fd # ausführen
git clean -fdx # Löschen Sie auch die ignorierten in .gitignore (z. B. node_modules)
(Alte Schreibweise) Arbeitsbereichsänderungen verwerfen, entspricht der Git-WiederherstellungGefahr
git checkout -- src/app.js
Korrigieren Sie den Autor des letzten CommitsAchtung
git commit --amend --author="Zhang San <zs@example.com>" --no-edit
Nicht erreichbare Objekte auflisten, ein letzter Ausweg, wenn Reflog nicht verfügbar ist
git fsck --lost-found
git show <dangling-commit-id>
Stash abrufen, der versehentlich gelöscht wurde (Stash ist im Wesentlichen eine Übermittlung)
Verstecken Sie sogar nicht verfolgte neue Dateien (nicht standardmäßig enthalten)
git stash -u
git stash -a # Selbst ignorierte Dateien sammeln
Alle Stash auflisten (stash@{0} aktuell)
git stash list
Entfernen Sie die neueste Stash-Anwendung aus dem Arbeitsbereich und löschen Sie sie
git stash pop
git stash pop stash@{2}
Stash anwenden, aber behalten (wenn dieselbe Änderung in mehreren Branches verwendet wird)
git stash apply stash@{1}
Sehen Sie, was an einem bestimmten Stash geändert wurde
git stash show -p stash@{0}
Löschen Sie einen StashGefahr
git stash drop stash@{0}
git stash clear # alles löschen
Erstellen Sie einen neuen Branch aus dem Stash und wenden Sie ihn an (das ist am einfachsten, wenn der Stash mit dem aktuellen Branch in Konflikt steht).
git stash branch fix-from-stash stash@{0}
Stashen Sie nur die angegebenen Dateien
git stash push -m »Nur Stile reduzieren« – src/styles/
Etikett
8 Befehle· Veröffentlichungen markieren
Listen-Tags
git tag
git tag -l "v1.*" # Nach Muster filtern
Hinweis-Tag: mit Autor, Datum, Beschreibung, verwenden Sie dies für veröffentlichte Versionen
git tag -a v1.2.0 -m "Release 1.2.0"
Lightweight-Tag: nur ein Name, der auf das Commit verweist
git tag build-2026-09-09
Fügen Sie Tags zu einem Commit im Verlauf hinzu
git tag -a v1.1.1 a1b2c3d -m »make up«
Tag-Informationen und entsprechende Einsendungen anzeigen
git show v1.2.0
Lokales Label löschenAchtung
git tag -d v1.2.0
Remote-Label löschenAchtung
git push origin --delete v1.2.0
Beschreiben Sie den aktuellen Commit mit dem aktuellsten Tag (v1.2.0-3-gabc1234: 3 Commits nach v1.2.0)
git bisect start
git bisect bad # Derzeit schlecht
git bisect good v1.1.0 # Diese Version ist gut
# Wiederholt testen und git bisect gut/schlecht ausführen
git bisect reset
Lassen Sie das Skript automatisch feststellen, ob es gut oder schlecht ist, und teilen Sie es automatisch in zwei Teile.
git bisect run npm test
Suche innerhalb verfolgter Dateien (schneller als grep -r und durchsucht nicht node_modules)
git grep -n "TODO" -- "*.ts"
git grep »foo« v1.0 # Suche in einer bestimmten Version
Zeigen Sie den Inhalt einer bestimmten Version einer Datei direkt an, ohne Branches abzuschneiden
git show HEAD~5:src/config.js > old-config.js
Nur geänderte Dateinamen auflisten
git diff --name-only HEAD~3 HEAD
git diff --name-status main # mit M/A/D-Status
Zeigen Sie die Anzahl und den belegten Platz von Lagerobjekten an
git count-objects -vH
Packen Sie Objekte, bereinigen Sie den Müll, minimieren Sie .gitAchtung
git gc --aggressive --prune=now
Prune löscht tatsächlich die nicht erreichbaren Objekte und die Reue-Medizin im Reflog verschwindet zusammen.
Analysieren Sie die Referenz in die vollständige Commit-ID. --abbrev-ref ruft den Filialnamen ab
git rev-parse --short HEAD
git rev-parse --abbrev-ref HEAD
git rev-parse --show-toplevel # Warehouse-Stammverzeichnis
Exportieren Sie eine bestimmte Version der Datei in ein komprimiertes Paket (außer .git).
git archive -o release.zip v1.2.0
git archive HEAD src/ | tar -x -C /tmp/out
Ignorieren und Attribute
7 Befehle· .gitignore / .gitattributes / große Dateien
Ein Muster pro Zeile: node_modules/, *.log, !keep.log (negiert), /build (nur Stammverzeichnis)
Mehrere Befehle zu einem Rezept für eine Aufgabe bündeln; nach dem Ausklappen lässt sich alles zusammen kopieren.
Machen Sie den letzten Commit rückgängig, aber behalten Sie die Änderungen bei
Die Einreichung war zu früh / die Beschreibung wurde falsch geschrieben / Ich möchte sie in zwei Einreichungen aufteilen (und sie wurde noch nicht gepusht)
git reset --soft HEAD~1Senden und zurückziehen, Änderungen befinden sich noch im Staging-Bereich
git statusBestätigen Sie, dass sich alle Dateien unter »Zu übermittelnde Änderungen« befinden.
git commit -m »neue Beschreibung«
Machen Sie einen bereits gepushten Commit rückgängig
Andere haben es vielleicht schon genommen, die Geschichte kann nicht neu geschrieben werden.
git revert <commit>Reverse-Commit generieren
git push
Rollback auf eine Version (lokal)Gefahr
Das lokale Experiment ist durcheinander und ich möchte vollständig zu einem bestimmten Commit zurückkehren
git log --onelineSuchen Sie die Ziel-Commit-ID
git stash -u(Optional) Reduzieren Sie zunächst die Änderungen, die Sie behalten möchten
git reset --hard <commit>
Im Hauptzweig eingereicht und möchte in einen neuen Branch wechselnAchtung
Ich habe vergessen, eine Branch zu eröffnen und habe sie N-mal eingereicht.
git branch feature/xErstellen Sie einen Branch am aktuellen Standort (»speichern« Sie diese Commits).
git reset --hard origin/mainmain kehrt in den Remote-Zustand zurück
git switch feature/x
Kombinieren Sie mehrere fragmentarische Einreichungen zu einerAchtung
Organisieren Sie den Verlauf, bevor Sie eine PR eröffnen (die Branch wird nicht von anderen genutzt)
git rebase -i HEAD~4Ändern Sie »pick« in den folgenden Zeilen in »squash« oder »fixup«.
git push --force-with-leaseNur erforderlich, wenn der Branch gepusht wurde
Lassen Sie den Funktionszweig mit dem neuesten Fortschritt von main Schritt halten
main hat einen neuen Commit und der Feature-Branch sollte darüber hinaus fortgesetzt werden
git fetch origin
git switch feature/x
git rebase origin/mainoder git merge origin/main (Merge-Commits beibehalten)
Master in Main umbenennen (einschließlich Remote)Achtung
Vereinheitlichen Sie den Standardzweignamen
git branch -m master main
git push -u origin main
git push origin --delete masterSchneiden Sie zunächst den Standardzweig auf der Hosting-Plattform auf »main« ab
Rufen Sie versehentlich gelöschte Branches ab
Ich fand es nach git branch -D nützlich
git reflogSuchen Sie die ID des letzten Commits des Zweigs (z. B. »Commit: xxx«).
git branch <name> <commit-id>
Schlüssel/große Datei wurde versehentlich übermitteltGefahr
.env oder Hunderte von MB-Dateien wurden in den Verlauf eingetragen
git rm --cached .env && echo ".env" >> .gitignoreWenn nur das letzte Commit durchgeführt wird: dann git commit --amend
git filter-repo --path .env --invert-pathsBereits tief in der Geschichte: Schreiben Sie den gesamten Verlauf mit git-filter-repo neu (muss separat installiert werden)
git push --force-with-lease --allAlle Mitarbeiter müssen erneut geklont werden; Durchgesickerte Schlüssel müssen auf jeden Fall ungültig gemacht und erneut ausgestellt werden
Bringen Sie einen Fix in den Release-Branch
Auf der Hauptversion behobene Fehler werden ebenfalls auf Release/1.2 verschoben
git switch release/1.2
git cherry-pick <commit>
git push
Prozess zur Bearbeitung von Konfliktstandards zusammenführen
git merge/pull report KONFLIKT
git statusSehen Sie, welche Dokumente »von beiden Parteien geändert« wurden
code <file>Verarbeiten Sie <<<<<<< ======= >>>>>>>-Tags im Editor und behalten Sie dabei den korrekten Inhalt bei
git add <file>Fügen Sie eins hinzu, nachdem jedes behoben wurde
git commitBeim Rebase: git rebase --continue
Wenn lokal ein Projekt vorhanden ist, verschieben Sie es in das neue leere Remote-Warehouse
Ich habe den Code zuerst lokal geschrieben und dann ein Warehouse auf GitHub erstellt.
git init -b main && git add -A && git commit -m "init"
Diagramm: Was jede Aktion mit dem Commit-Graphen macht
Kreise sind Commits, Pfeile zeigen auf den Eltern-Commit; grüne Labels sind Branches, violette markieren den Branch, auf dem HEAD steht; graue Kreise werden von keinem Branch mehr referenziert (über reflog wiederherstellbar), gefüllte Kreise sind die in dieser Aktion neu erzeugten Commits.
Commit: einen Knoten an der Spitze des aktuellen Branches anhängen
git add . && git commit -m "…"
Jeder Commit kennt seinen Eltern-Commit; ein Branch ist nur ein beweglicher Zeiger auf einen Commit, deshalb wandern main und HEAD nach einem Commit zusammen vorwärts.
Branch anlegen: nur ein Zeiger, keine Dateikopie
git switch -c feature
Der neue Branch und main zeigen auf denselben Commit, deshalb ist das Anlegen sofort erledigt; Commits auf feature bewegen danach nur feature vorwärts.
Fast-Forward-Merge: Zeiger direkt verschieben, wenn main keine eigenen Commits hat
git switch main && git merge feature
Es entsteht kein neuer Commit und die Historie bleibt eine gerade Linie. Wer die Spur eines ehemaligen Branches behalten will, verwendet --no-ff.
Drei-Wege-Merge: Bei neuen Commits auf beiden Seiten entsteht ein Merge-Commit
git merge feature
Git sucht den gemeinsamen Vorfahren b2, führt die Änderungen beider Seiten relativ zu b2 zusammen und erzeugt m6 mit zwei Eltern-Commits. Ein Konflikt entsteht nur, wenn dieselbe Stelle unterschiedlich geändert wurde.
Rebase: Commits aus feature auf main neu abspielen
git switch feature && git rebase main
Die Historie wird zu einer geraden Linie, aber c3 und d4 werden durch die neuen Commits c3′ und d4′ ersetzt (die ids ändern sich). Ein bereits gepushter Branch sollte nicht rebased werden, sonst weicht die Historie der anderen von der eigenen ab.
reset: den Branch-Zeiger zurückziehen (Commits werden vorerst zu Waisen)
git reset --hard HEAD~1
--soft bewegt nur den Zeiger; --mixed leert zusätzlich den Staging-Bereich; --hard setzt auch das Arbeitsverzeichnis zurück. Der verwaiste Commit c3 lässt sich weiterhin über das reflog wiederfinden (standardmäßig mindestens 30 Tage lang).
revert: mit einem Gegen-Commit rückgängig machen, ohne die Historie umzuschreiben
git revert HEAD
c3 bleibt in der Historie; der neue Commit r4 enthält genau die Umkehrung der Änderungen von c3. Für bereits gepushte Commits nimmt man revert statt reset.
cherry-pick: einen einzelnen Commit übernehmen
git cherry-pick x7
Wendet die Änderung, die x7 gegenüber seinem Eltern-Commit eingeführt hat, auf main an und erzeugt x7′ mit gleichem Inhalt und anderer id. So bringt man einen einzelnen Fix auf einen Release-Branch.
Übungsterminal: im Browser direkt ausprobieren
Ein reiner In-Memory-Git-Simulator (kein echtes Git und ohne Netzwerk): unterstützt die gängigen Subcommands init / add / commit / branch / switch / merge / rebase / reset / revert / stash / tag / remote / push / pull, und der Commit-Graph rechts aktualisiert sich live. 10 Level führen von "der erste Commit" bis "einen Merge-Konflikt lösen". Die Linux-Befehlsübung findet sich inLinux-Befehlsübersicht.
Toolun Git-Übungsterminal – ein Git im Arbeitsspeicher, mit dem frei experimentiert werden kann, ohne etwas kaputtzumachen.
Mit git help werden die unterstützten Unterbefehle angezeigt; rechts eine Lektion wählen und die Ziele ausführen – nach jedem Befehl aktualisiert sich der Commit-Graph.