Git-Spickzettel — Befehle nach Aufgabe
Git-Befehle geordnet nach dem, was du tun willst: letzten Commit rückgängig machen, Branch umbenennen, Remote-Branch löschen. Modernes switch/restore mit klassischen Entsprechungen und Warnhinweisen.
Zuletzt geprüft: 2026-10-18, abgeglichen mit der git-scm.com-Referenz für Git 2.56 und dem Handbuch der GitHub CLI. Quellen: Git reference (git-scm.com/docs), git restore, git switch, git reset, git config, GitHub CLI manual.
Einrichtung (einmal pro Rechner)
Mit --global landen Einstellungen in ~/.gitconfig. Seit Git 2.46 ist git config set / get / list die dokumentierte Form; die klassische Form funktioniert weiterhin.
git config set --global user.name "Ana Lee" git config set --global user.email "ana@example.com"
Klassisch: git config --global user.name "Ana Lee"
Wird in jedem deiner Commits gespeichert. Nutze die E-Mail-Adresse, die dein Git-Host kennt, damit Commits mit deinem Konto verknüpft werden.
git config set --global init.defaultBranch main
Klassisch: git config --global init.defaultBranch main
Ohne diese Einstellung nennt git init den ersten Branch weiterhin master (und gibt einen Hinweis aus).
git config set --global core.editor "code --wait"
Klassisch: git config --global core.editor "code --wait"
Jeder Befehl, der wartet, bis die Datei geschlossen ist, funktioniert: "nano", "vim", "subl -n -w".
git config set --global core.autocrlf true # Windows git config set --global core.autocrlf input # macOS, Linux
Klassisch: git config --global core.autocrlf true
Committet LF, checkt unter Windows CRLF aus. Für ein ganzes Team ist eine .gitattributes-Datei mit "* text=auto" zuverlässiger als persönliche Einstellungen.
git --version
git switch und git restore brauchen 2.23+, die git config-Unterbefehle 2.46+.
Repository anlegen
git init
git init -b main # name the first branchLegt ein .git-Verzeichnis an. Füge vor dem ersten Commit eine .gitignore hinzu, damit Build-Ausgaben und Secrets gar nicht erst hineingeraten.
git clone https://github.com/owner/repo.git git clone git@github.com:owner/repo.git my-folder
Lädt die komplette Historie herunter und richtet das Remote "origin" ein. Die zweite Form nutzt SSH und einen eigenen Ordnernamen.
git clone --depth 1 https://github.com/owner/repo.git
Überspringt die Historie; gut für CI und große Repositorys. git fetch --unshallow holt den Rest später.
git remote add origin git@github.com:owner/repo.git git push -u origin main
Leg zuerst das leere Repository beim Host an (oder nutze gh repo create, siehe unten). -u merkt sich origin/main als Upstream.
Stagen und committen
git status
git status -s # short formListet gestagte, nicht gestagte und nicht verfolgte Dateien auf und schlägt den nächsten Befehl vor.
git add file.txt
git add . # everything in this folder and belowgit add -A stagt auch Löschungen überall im Repository.
git add -p file.txt
Geht jede Änderung („Hunk“) durch: y zum Stagen, n zum Überspringen, s zum Aufteilen, e zum Bearbeiten.
git commit -m "Add login form"
git commit -am "Fix typo" # stage tracked files and commit-a nimmt geänderte und gelöschte verfolgte Dateien mit, aber nie neue.
git mv old.txt new.txt git rm file.txt
Beide stagen die Änderung für dich. Git erkennt Umbenennungen am Inhalt, also funktioniert auch ein einfaches mv plus git add.
git rm --cached .env echo ".env" >> .gitignore
Entfernt sie ab dem nächsten Commit aus dem Repository. In früheren Commits bleibt sie erhalten: Enthielt sie ein Secret, tausch das Secret aus.
Branches
git branch git branch -a # include remote branches git branch -vv # show upstream and ahead/behind
Der aktuelle Branch ist mit * markiert.
git switch -c feature/login
Klassisch: git checkout -b feature/login
Startet beim aktuellen Commit; gib einen Startpunkt an, um woanders abzuzweigen: git switch -c hotfix origin/main.
git switch main
git switch - # back to the previous branchKlassisch: git checkout main
Gibt es nur origin/feature, legt git switch feature automatisch einen lokalen Tracking-Branch an.
git branch -m new-name # current branch
git branch -m old-name new-nameBenennt nur lokal um. Wie du ihn auch auf dem Remote umbenennst, steht im nächsten Eintrag.
git branch -m old-name new-name git push -u origin new-name git push origin --delete old-name
Ein Umbenennen auf dem Remote gibt es nicht: Push den neuen Namen und lösch den alten. Offene Pull Requests auf den alten Namen können dabei geschlossen werden; der Umbenennen-Button in der GitHub-Weboberfläche leitet sie um.
git branch -d feature/login
git branch -D feature/login # even if unmerged-d verweigert das Löschen, wenn der Branch Commits hat, die nicht in seinen Upstream oder HEAD gemergt sind; -D löscht trotzdem.
Wiederherstellung: Nicht gemergte Commits stehen noch im Reflog: git reflog, die Spitze suchen, dann git branch feature/login <sha>.
git push origin --delete feature/login
Klassisch: git push origin :feature/login
Teammitglieder sehen ihn weiterhin, bis sie git fetch --prune ausführen.
Wiederherstellung: Wer den Branch lokal hat (oder du über git reflog), kann ihn wieder pushen.
git branch -u origin/main
git push -u origin HEAD # push current branch and track itKlassisch: git branch --set-upstream-to=origin/main
Den Upstream nutzen ein einfaches git pull und git push.
git switch --detach a1b2c3d
git switch -c rescue # keep work made thereKlassisch: git checkout a1b2c3d
Commits im Detached-Zustand gehören zu keinem Branch; leg einen an, bevor du wegwechselst, sonst sind sie nur noch über den Reflog erreichbar.
Merge, Rebase und Cherry-Pick
git switch main
git merge feature/login
git merge --no-ff feature/login # always create a merge commitSpult wenn möglich vor (Fast-Forward); --no-ff hält den Branch in der Historie sichtbar.
git merge --squash feature/login git commit -m "Add login"
Stagt die kombinierten Änderungen, ohne einen Merge aufzuzeichnen; der Branch gilt danach nicht als gemergt.
git status # list conflicted files # edit the files, remove <<<<<<< ======= >>>>>>> markers git add file.txt git commit # or: git rebase --continue
Eine Seite komplett übernehmen mit git restore --ours file.txt oder --theirs. Bei einem Rebase ist "ours" der Branch, auf den rebased wird – umgekehrt wie beim Merge.
git merge --abort
Kehrt zum Zustand vor Beginn des Merges zurück.
Wiederherstellung: Bereits gelöste Konflikte gehen verloren. Hattest du beim Start des Merges nicht committete Änderungen, kann --abort sie eventuell nicht wiederherstellen – also vor dem Mergen committen oder stashen.
git switch feature/login git rebase main
Spielt deine Commits für eine lineare Historie oben auf main neu ab. Konflikte lösen, git add, dann git rebase --continue; --abort bricht ab.
Wiederherstellung: Direkt danach: git reset --hard ORIG_HEAD. Später: die alte Spitze in git reflog suchen.
git rebase -i HEAD~3
Öffnet eine Liste: pick in squash/fixup ändern zum Zusammenfassen, reword zum Bearbeiten einer Nachricht, drop zum Löschen, oder Zeilen umsortieren.
Wiederherstellung: git reflog zeigt den Commit vor dem Rebase; git reset --hard <sha> stellt ihn wieder her.
git commit --fixup=a1b2c3d git rebase -i --autosquash a1b2c3d~1
Der Fixup-Commit wird beim Rebase automatisch in a1b2c3d eingearbeitet.
Wiederherstellung: Wie beim interaktiven Rebase: git reflog.
git pull --rebase
git config set --global pull.rebase true # make it the defaultRebased deine lokalen Commits auf das, was geholt wurde.
git cherry-pick a1b2c3d
git cherry-pick -x a1b2c3d # note the source in the messageErstellt einen neuen Commit mit denselben Änderungen. Ein Bereich: git cherry-pick A..B (ohne A).
Remotes: fetch, pull, push
git remote -v git remote set-url origin git@github.com:owner/repo.git
set-url stellt einen Klon von HTTPS auf SSH um (oder auf ein umbenanntes Repository).
git fetch
git fetch --prune # also drop deleted remote branchesAktualisiert nur origin/*; deine Branches bleiben unberührt.
git pull
git fetch plus Merge (oder Rebase, wenn pull.rebase gesetzt ist).
git push
git push -u origin HEAD # first push of a new branch
git config set --global push.autoSetupRemote trueMit push.autoSetupRemote (Git 2.37+) setzt ein einfaches git push auf einem neuen Branch den Upstream selbst.
git push --force-with-lease
Anders als --force verweigert es den Push, wenn das Remote Commits hat, die du noch nicht geholt hast. Mit --force-if-includes (Git 2.30+) bist du bei Fetches im Hintergrund zusätzlich abgesichert.
Wiederherstellung: Überschriebene Remote-Commits überleben im Reflog derer, die sie hatten, und GitHub hält sie eine Weile über ihren SHA erreichbar.
git remote add upstream https://github.com/original/repo.git git fetch upstream git switch main git merge upstream/main
Oder mit der GitHub CLI: gh repo sync.
Dinge rückgängig machen
Wähle danach, wo der Fehler steckt: im Arbeitsverzeichnis, in der Staging Area, in einem lokalen Commit oder in einem bereits gepushten Commit. Alles, was jemals committet wurde, lässt sich meist mit git reflog wiederfinden; nicht committete Änderungen, die du verwirfst, nicht.
git reset --soft HEAD~1
Der Commit verschwindet; seine Änderungen bleiben gestagt und können neu committet werden. Mit git reset HEAD~1 (ohne --soft) bleiben sie stattdessen ungestagt.
Wiederherstellung: git reset ORIG_HEAD holt den Commit zurück. War er schon gepusht, nimm stattdessen git revert.
git reset --hard HEAD~1
Setzt den Branch um einen Commit zurück und bringt jede verfolgte Datei auf diesen Stand.
Wiederherstellung: Der Commit steht in git reflog (nicht erreichbare Einträge verfallen standardmäßig nach 30 Tagen): git reset --hard HEAD@{1}. Nicht committete Änderungen in verfolgten Dateien sind endgültig weg.
git revert a1b2c3d
git revert HEAD # the latest commitFügt einen neuen Commit hinzu, der den alten umkehrt, sodass sich die Historie der anderen nicht ändert. Das ist das sichere Rückgängigmachen für geteilte Branches.
git revert -m 1 <merge-sha>
-m 1 behält den ersten Parent (meist main). Wer den Branch später erneut mergen will, muss zuerst diesen Revert reverten.
git commit --amend -m "Better message"
Ersetzt den letzten Commit durch einen neuen. Vor dem Pushen unproblematisch; danach ist --force-with-lease nötig.
Wiederherstellung: git reset --soft HEAD@{1} kehrt zum Commit vor dem Amend zurück.
git add forgotten.txt git commit --amend --no-edit
Behält die Nachricht und fügt die Datei hinzu.
Wiederherstellung: git reset --soft HEAD@{1}.
git restore --staged file.txt
git restore --staged . # everythingKlassisch: git reset HEAD file.txt
Die Änderungen bleiben im Arbeitsverzeichnis; nur das Staging wird rückgängig gemacht.
git restore file.txt
Klassisch: git checkout -- file.txt
Setzt die Datei auf die gestagte Version zurück (oder auf den letzten Commit, wenn nichts gestagt ist).
Wiederherstellung: Mit Git nicht wiederherstellbar: Die Änderungen wurden nie committet. Der lokale Verlauf deines Editors hat sie eventuell noch.
git restore --staged --worktree .
git clean -fd # also delete untracked filesKlassisch: git reset --hard
git clean -fd
Zurück zum letzten Commit. Führ vorher git clean -n aus, um zu sehen, was gelöscht würde.
Wiederherstellung: Nicht wiederherstellbar: Nicht committete Änderungen und nicht verfolgte Dateien werden gelöscht. git stash -u ist die umkehrbare Alternative.
git restore file.txt # deletion not committed git restore --source=a1b2c3d~1 file.txt # deleted in commit a1b2c3d
Klassisch: git checkout a1b2c3d~1 -- file.txt
Den Commit, der sie gelöscht hat, findest du mit git log --diff-filter=D -- file.txt.
git restore --source=main -- config.yml
Klassisch: git checkout main -- config.yml
Überschreibt nur die Arbeitskopie; mit --staged --worktree wird sie auch gestagt. Nur ansehen: git show main:config.yml.
Wiederherstellung: Nicht committete Änderungen an dieser Datei werden überschrieben.
git reflog git branch rescued a1b2c3d
Der Reflog zeichnet jede Stelle auf, an der HEAD war. Such den SHA von vor dem Fehler und setz einen Branch darauf.
git reset --hard ORIG_HEAD
ORIG_HEAD wird von merge, rebase und reset auf den vorherigen Stand gesetzt. Der nächste solche Befehl überschreibt es.
Wiederherstellung: git reflog listet den Merge-Commit weiterhin.
git reflog # find "rebase (start)"; the entry below it is the old tip
git reset --hard HEAD@{5}Direkt nach dem Rebase erledigt git reset --hard ORIG_HEAD dasselbe.
Wiederherstellung: --hard verwirft nicht committete Änderungen; stash sie vorher.
git reset --hard HEAD@{1}HEAD@{1} ist die Stelle, an der HEAD vor der letzten Bewegung war. Funktioniert nur für committete Arbeit.
git filter-repo --invert-paths --path secrets.env
git filter-repo ist ein separates Tool (pip install git-filter-repo), das die git-filter-branch-Dokumentation empfiehlt. Danach muss jeder Klon neu geklont werden. Tausch das Secret trotzdem aus: Es war ab dem Moment des Pushs öffentlich.
Wiederherstellung: filter-repo arbeitet auf einem frischen Klon; behalte den alten Klon, bis du sicher bist.
Stash
git stash
git stash push -m "half-done login"
git stash -u # include untracked filesSichert verfolgte Änderungen und räumt das Arbeitsverzeichnis auf, damit du den Branch wechseln kannst.
git stash pop # apply and drop git stash apply stash@{1} # apply, keep the stash
Konflikte sind möglich; bei pop bleibt der Stash erhalten, wenn das Anwenden fehlschlägt.
git stash list
git stash show -p stash@{0}Neueste zuerst; stash@{0} ist der jüngste.
git stash push -- src/login.ts
git stash push --staged # only what is staged (2.35+)Auf Pfade beschränkte Stashes lassen alles andere, wie es ist.
git stash branch feature/login stash@{0}Legt den Branch beim Commit an, auf dem du gestasht hast, wendet den Stash an und verwirft ihn; vermeidet Konflikte.
git stash drop stash@{0}
git stash clearclear entfernt jeden Stash.
Wiederherstellung: Ein verworfener Stash ist bis zur Garbage Collection ein nicht erreichbarer Commit: git fsck --unreachable | grep commit, dann git stash apply <sha>.
Historie und Diffs
git log --oneline --graph --all
Eine Zeile pro Commit mit Branch-Struktur. Bei sehr altem Git --decorate ergänzen, um Branch-Namen zu sehen.
git log --follow -p -- path/file.txt
--follow verfolgt sie über Umbenennungen hinweg; -p zeigt jede Änderung.
git log -S "functionName" --oneline git log -G "regex" --oneline
-S zählt, ob sich die Anzahl der Vorkommen ändert; -G prüft jede geänderte Zeile gegen eine Regex.
git log --author="Ana" --since="2 weeks ago" --oneline
Außerdem --until, --grep="fix" für Nachrichten und main..feature für Commits, die auf feature, aber nicht auf main liegen.
git show a1b2c3d git show a1b2c3d:path/file.txt
Die zweite Form gibt die Datei so aus, wie sie in diesem Commit war, ohne deine Kopie anzufassen.
git diff # unstaged git diff --staged # staged, i.e. what will be committed
--stat fasst pro Datei zusammen; --word-diff eignet sich besser für Fließtext.
git diff main...feature # changes on feature since it branched git diff main feature # the two tips directly
Drei Punkte vergleichen mit der Merge-Basis – genau das, was ein Pull Request zeigt.
git blame -L 10,20 path/file.txt
Mit -w werden Leerzeichen ignoriert, mit -C werden Zeilen verfolgt, die aus anderen Dateien verschoben wurden.
git bisect start git bisect bad # current commit is broken git bisect good v1.4.0 # this one worked # test, then mark each step good or bad git bisect reset
Binäre Suche: etwa log2(n) Schritte. git bisect run ./test.sh automatisiert das.
git grep -n "TODO"
Schneller als grep bei großen Repositorys und überspringt ignorierte Dateien. Gib einen Commit an, um eine alte Version zu durchsuchen.
Tags und Releases
git tag -a v1.2.0 -m "Release 1.2.0"
git tag -a v1.1.1 a1b2c3d -m "Hotfix" # tag an older commitAnnotierte Tags (-a) speichern Autor, Datum und Nachricht; nimm sie bevorzugt für Releases. git tag v1.2.0 allein erzeugt ein Lightweight-Tag.
git tag -d v1.2.0 git push origin --delete v1.2.0
Verwende den Namen eines gelöschten Release-Tags nicht erneut: Andere Klone behalten das alte Tag.
Wiederherstellung: Der getaggte Commit bleibt unberührt; leg das Tag einfach neu darauf an.
Submodule und Worktrees
git submodule add https://github.com/owner/lib.git vendor/lib git commit -m "Add lib submodule"
Speichert die URL in .gitmodules und pinnt einen exakten Commit des anderen Repositorys.
git clone --recurse-submodules <url>
git submodule update --init --recursive # already clonedOhne das bleiben Submodul-Ordner leer.
git submodule update --remote git commit -am "Bump submodules"
Holt den verfolgten Branch jedes Submoduls; committe die neuen Pins im übergeordneten Repository.
git worktree add ../repo-hotfix hotfix git worktree add -b review ../repo-review origin/main
Ein zweiter Arbeitsordner, der dasselbe Repository nutzt; kein Stash und kein zweiter Klon nötig.
git worktree list
git worktree remove ../repo-hotfix
git worktree prune # forget folders deleted by handremove verweigert, wenn der Worktree nicht committete Änderungen hat (mit --force erzwingen).
Aufräumen
git clean -n -d
Führ das immer vor git clean -f aus.
git clean -fd # untracked files and folders git clean -fdx # also ignored files (build output, .env!)
-x entfernt auch ignorierte Dateien, darunter lokale Konfiguration wie .env.
Wiederherstellung: Nicht wiederherstellbar: Diese Dateien waren nie in Git.
git branch --merged main git branch -d branch-a branch-b
Prüf vorher die Liste; -d verweigert nicht gemergte Branches, du kannst es also gefahrlos probieren.
git fetch --prune git config set --global fetch.prune true
Entfernt origin/*-Refs, deren Branches auf dem Server gelöscht wurden.
git maintenance start git gc
maintenance start plant Hintergrundjobs für Prefetch, Commit-Graph und Repack; gc packt Objekte und entfernt nicht erreichbare sofort.
Konfiguration und Aliase
git config list --show-origin
Klassisch: git config --list --show-origin
Zeigt System-, globale und Repository-Werte samt der Datei, in der sie jeweils stehen.
git config set --global alias.st "status -s" git config set --global alias.lg "log --oneline --graph --all"
Klassisch: git config --global alias.st "status -s"
Danach git st und git lg. Mit vorangestelltem ! führst du einen Shell-Befehl aus: alias.root "!pwd".
git config set --global pull.rebase true git config set --global push.autoSetupRemote true git config set --global rerere.enabled true git config set --global merge.conflictStyle zdiff3 git config set --global diff.algorithm histogram
Klassisch: git config --global pull.rebase true
Rebase beim Pull; automatischer Upstream beim ersten Push (2.37+); Konfliktlösungen merken; gemeinsamen Vorfahren in Konflikten anzeigen (2.35+); übersichtlichere Diffs.
git config set --global core.excludesFile ~/.gitignore_global
Klassisch: git config --global core.excludesFile ~/.gitignore_global
Für Kram von Betriebssystem und Editor (.DS_Store, .idea/). Projektspezifische Regeln gehören in die .gitignore des Repositorys.
Grundlagen der GitHub CLI (gh)
gh ist das eigene Kommandozeilentool von GitHub und wird getrennt von Git installiert.
gh auth login
gh auth setup-git # let git use gh for HTTPS credentialsÖffnet einen Browser oder nimmt ein Token entgegen; funktioniert für github.com und GitHub Enterprise.
gh repo create my-app --private --source=. --push
Erstellt das Repository, fügt es als origin hinzu und pusht den aktuellen Branch.
gh repo clone owner/repo
Bei einem Fork wird zusätzlich das Eltern-Repository als Remote „upstream“ hinzugefügt.
gh pr create --fill gh pr create --draft --title "WIP: login" --body "…"
--fill übernimmt die Commit-Nachrichten für Titel und Beschreibung.
gh pr checkout 123
Holt den PR-Branch (auch aus Forks) und wechselt zu ihm.
gh pr list gh pr view 123 --web gh pr merge 123 --squash --delete-branch
gh pr status zeigt die PRs, die für dich relevant sind.
gh issue create --title "Bug: …" --body "…" gh issue list --assignee @me
gh issue view 42 --comments liest einen Thread im Terminal.
gh run list gh run watch
gh run view --log-failed gibt nur die fehlgeschlagenen Schritte aus.
Brauchst du eine .gitignore als Ausgangspunkt? Nutze den .gitignore-Generator. Willst du zwei Versionen einer Datei außerhalb von Git vergleichen? Der Diff-Checker zeigt die Änderungen nebeneinander.
Eine statische Referenz: Die Suche läuft in deinem Browser, und nichts von dem, was du eingibst, wird irgendwohin gesendet. Alle kostenlosen Tools ansehen.
Ein Problem gefunden oder etwas, das besser sein könnte? Wir lesen jede Nachricht und beheben Fehler schnell.
Dieser Git-Spickzettel ist nach Aufgaben geordnet, nicht nach Befehlen – denn niemand sucht nach „git reset --soft“, sondern nach „letzten Commit rückgängig machen“. Finde, was du vorhast, kopiere den Befehl und lies die einzeilige Erklärung, was er verändert. Die Suche stellt Aufgaben an die Spitze, „delete remote branch“ oder „rename branch“ führen also direkt zum richtigen Eintrag.
Befehle, die die History umschreiben oder Arbeit wegwerfen, sind markiert, mit einem Hinweis, was sich wiederherstellen lässt: Fast alles, was jemals committet wurde, findest du mit git reflog wieder, während nicht committete Änderungen, die du mit restore, reset --hard oder clean verwirfst, weg sind. Wo Git inzwischen einen klareren Befehl hat (git switch und git restore seit 2.23, git config set und list seit 2.46), steht dieser zuerst und die klassische Form daneben – so funktioniert der Spickzettel, egal ob dein Team Git letztes Jahr oder 2010 gelernt hat. Geprüft anhand der Referenz auf git-scm.com für Git 2.56.
So funktioniert’s
- Tippe ins Suchfeld, was du tun willst, etwa „undo last commit“, „unstage“ oder „squash commits“, oder klicke auf eine der häufigen Aufgaben.
- Lies die Hinweise, bevor du etwas ausführst: Gelb bedeutet, dass der Befehl die History umschreibt, Rot, dass er Arbeit verwerfen kann. Der Hinweis zur Wiederherstellung sagt dir, wie du zurückkommst.
- Klicke auf „Befehl kopieren“. Die Kopie lässt die #-Kommentare weg, damit sie sich sauber ins Terminal einfügen lässt; ersetze Platzhalter wie a1b2c3d oder feature/login durch deine eigenen.
- Teile eine bestimmte Antwort über den #-Link neben jeder Aufgabe oder drucke den ganzen Spickzettel als zweispaltiges PDF.
Häufige Fragen
Wie mache ich den letzten Commit in Git rückgängig?
Wenn du ihn noch nicht gepusht hast, entfernt git reset --soft HEAD~1 den Commit und lässt seine Änderungen in der Staging-Area, git reset HEAD~1 lässt sie ungestaged im Arbeitsverzeichnis. git reset --hard HEAD~1 entfernt den Commit samt Änderungen. Ist der Commit schon auf einen gemeinsamen Branch gepusht, nimm stattdessen git revert HEAD: Das fügt einen neuen Commit hinzu, der ihn rückgängig macht, ohne die History anderer umzuschreiben.
Was ist der Unterschied zwischen git reset, git restore und git revert?
git restore ändert Dateien: Es verwirft Änderungen im Arbeitsverzeichnis oder nimmt sie aus der Staging-Area, verschiebt aber nie einen Branch. git reset verschiebt den aktuellen Branch auf einen anderen Commit (und überschreibt mit --hard auch deine Dateien), schreibt also die History um. git revert erzeugt einen neuen Commit, der das Gegenteil eines früheren anwendet; die History wächst nur, deshalb ist es die sichere Wahl auf Branches, die andere nutzen.
Wie benenne ich einen Git-Branch lokal und auf dem Remote um?
git branch -m new-name benennt den Branch um, auf dem du bist (git branch -m old new für einen anderen). Remotes kennen kein Umbenennen, also pushe den neuen Namen mit git push -u origin new-name und lösche den alten mit git push origin --delete old-name. Auf GitHub werden beim Umbenennen über die Weboberfläche auch offene Pull Requests umgestellt.
Sollte ich git switch oder git checkout verwenden?
Beides funktioniert. git checkout erledigt zwei voneinander unabhängige Aufgaben, Branches wechseln und Dateien wiederherstellen – deshalb hat Git 2.23 sie in git switch und git restore aufgeteilt. Die neuen Befehle sind klarer und schwerer falsch zu benutzen (git checkout -- file verwirft Änderungen stillschweigend), daher zeigt dieser Spickzettel sie zuerst. git checkout ist nicht veraltet, und jeder Befehl hier nennt seine klassische Entsprechung.
Kann ich einen Commit nach git reset --hard wiederherstellen?
Meistens ja. Führe git reflog aus, such die Zeile von vor dem Reset und führe git reset --hard HEAD@{n} aus oder lege einen Branch auf diesem SHA an. Commits bleiben standardmäßig 30 Tage über das Reflog erreichbar, nachdem nichts anderes mehr auf sie zeigt. Nicht wiederherstellen lässt sich nicht committete Arbeit: Änderungen, die nie committet oder gestasht wurden, sind endgültig überschrieben.
Was macht git push --force-with-lease?
Es überschreibt den Remote-Branch nur, wenn der Remote noch dort steht, wo dein letzter Fetch ihn gesehen hat. Hat jemand zwischenzeitlich gepusht, wird der Push abgelehnt, statt stillschweigend dessen Commits zu löschen – was ein einfaches --force tun würde. Nutze es nach einem Rebase oder Amend auf einem Branch, den du schon gepusht hast.
Welcher Undo-Befehl? Entscheide danach, wo die Änderung ist
• Datei bearbeitet und die Änderung soll weg: git restore file. Nicht wiederherstellbar, weil sie nie committet wurde.
• Versehentlich etwas gestaged: git restore --staged file. Nichts geht verloren; die Änderung bleibt in der Datei.
• Committet, aber nicht gepusht: git reset --soft HEAD~1, um den Commit neu zu machen, oder git commit --amend, um ihn direkt zu korrigieren.
• Committet und auf einen gemeinsamen Branch gepusht: git revert <sha>. Setze keinen Branch zurück, den andere schon gepullt haben.
• Einen Commit, einen Branch oder das Ergebnis eines missglückten Rebase verloren: git reflog, dann git branch rescued <sha>.
Die Regel dahinter: Alles, was Commits umschreibt, ist in Ordnung, solange die Commits nur dir gehören, und wird zum Problem aller, sobald sie geteilt sind.
Merge oder Rebase?
Beide holen die Änderungen eines Branches in einen anderen. Ein Merge hält fest, dass zwei Historien zusammengeführt wurden, mit einem Merge-Commit, der zwei Eltern hat; nichts wird umgeschrieben, auf gemeinsamen Branches ist das also immer sicher. Ein Rebase spielt deine Commits auf dem anderen Branch neu ab und erzeugt eine gerade Linie in der History, als hättest du beim neuesten Commit angefangen – dabei entstehen aber neue Commit-IDs, und wer die alten schon hat, muss sich damit abgleichen.
Eine verbreitete Team-Konvention: den eigenen Feature-Branch per Rebase auf main aktuell halten (git pull --rebase oder git rebase main) und den fertigen Branch über einen Pull Request in main mergen. Squash-Merges ergeben einen Commit pro Feature auf main; normale Merges behalten jeden Commit und die Form des Branches. Entscheide dich pro Repository für eine Variante und stell sie beim Hoster ein, damit die History einheitlich bleibt.
Git-Einstellungen, die sich vom Standard aus zu ändern lohnen
• pull.rebase true: git pull rebased, statt bei jedem Abgleich Merge-Commits anzulegen.
• push.autoSetupRemote true (Git 2.37+): Der erste git push eines neuen Branches setzt dessen Upstream, kein -u nötig.
• merge.conflictStyle zdiff3 (Git 2.35+): Konfliktmarker enthalten den gemeinsamen Vorfahren, wodurch die meisten Konflikte offensichtlich werden.
• rerere.enabled true: Git merkt sich, wie du einen Konflikt gelöst hast, und wendet die Lösung erneut an, wenn derselbe Konflikt bei einem Rebase wieder auftaucht.
• fetch.prune true: Auf dem Server gelöschte Remote-Branches verschwinden beim nächsten Fetch auch lokal.
• init.defaultBranch main: Neue Repositorys starten auf main.
Ähnliche kostenlose Tools
- .gitignore-Generator — Kombiniere .gitignore-Vorlagen für Sprachen, Frameworks, Editoren und Betriebssysteme zu einer sauberen Datei.
- Diff-Checker — Vergleiche zwei Versionen eines Textes, Codes oder einer JSON-Datei und sieh genau, welche Zeilen, Wörter und Zeichen sich geändert haben.
- Markdown-Spickzettel — Jedes Markdown-Element mit Quelltext und gerenderter Vorschau, erweiterte Syntax (Tabellen, Aufgabenlisten, Fußnoten, Mathematik, Mermaid, Hinweisboxen), eine Kompatibilitätstabelle für 9 Plattformen und ein Live-Playground.
- Regex-Spickzettel — Jedes Token regulärer Ausdrücke mit funktionierendem Beispiel, Unterstützung in JavaScript, PCRE/PHP, Python, Go, Java und .NET und einem „Ausprobieren“-Link, der den Regex-Tester vorausgefüllt öffnet.