Git Befehle Liste: Die 40 wichtigsten Befehle mit Beispielen (2026)

Git hat auf unserem Server laut git help -a genau 165 Befehle. Im Alltag benutzen wir davon vielleicht fünfzehn. Der Rest ist entweder Spezialwerkzeug oder interne Klempnerei, die du nie direkt anfassen musst. Genau deshalb ist eine Git Befehle Liste so nützlich: Sie trennt das, was du jeden Tag tippst, von dem, was du einmal im Jahr nachschlägst.

Diese Git Befehle Liste ist nach Situationen sortiert, nicht nach dem Alphabet. Erst die Einrichtung, dann der tägliche Kreislauf, dann Branches, dann Rückgängig machen, dann die Zusammenarbeit mit anderen und am Ende die Notfall- und Detektivbefehle. Zu jedem Befehl gibt es ein Beispiel, das du kopieren kannst. Alle Ausgaben und Zahlen stammen aus eigenen Tests vom 18. Oktober 2026 mit Git 2.43 auf unserem Ubuntu-Server: an einem Test-Repository mit 100 Commits und an einem frischen Klon von Express.js mit 6.182 Commits.

Falls du noch gar nicht weißt, was ein Commit oder ein Branch eigentlich ist, lies vorher unseren Grundlagenartikel Was ist Git?. Dort erklären wir das Modell dahinter. Hier geht es um die Befehle.

Wer die Befehle lieber einmal in Ruhe vorgeführt bekommt: Der Komplettkurs vom Data Science Institute (Mai 2026) ist der aktuellste deutschsprachige Einstieg, den wir gefunden haben. Diese Liste ist zum Nachschlagen gedacht, das Video zum Mitmachen.

Die Git Befehle Liste auf einen Blick

Wenn du nur eine Tabelle brauchst, hier ist sie. Die Details zu jedem Befehl folgen darunter.

Das sind 22 Zeilen. Mit diesen Befehlen kommst du durch 95 Prozent aller Arbeitstage. Unten erklären wir sie im Detail, dazu rund 20 weitere Varianten und Optionen, die du kennen solltest.

Einrichtung: die Befehle für den ersten Tag

Diese Befehle tippst du einmal pro Rechner und dann nie wieder.

git config: wer bist du?

git config --global user.name "Fabian Budde"
git config --global user.email "fabian@example.com"
git config --global init.defaultBranch main
git config --global pull.rebase false

Name und E-Mail landen in jedem Commit. Ohne sie verweigert Git das Speichern. init.defaultBranch main sorgt dafür, dass neue Repositories mit dem Branch main statt master starten. Bei unserem Test lief git init ohne diese Einstellung noch mit master los, obwohl GitHub, GitLab und die meisten Teams längst main nutzen. Das ist kein Drama, aber eine unnötige Quelle für Verwirrung, wenn lokal master und auf dem Server main heißt.

pull.rebase false beantwortet eine Frage, die Git dir sonst irgendwann stellt (dazu weiter unten mehr). Mit git config --list --show-origin siehst du alle aktiven Einstellungen und aus welcher Datei sie kommen.

git init und git clone: ein Repository beginnen

# Neues Projekt im aktuellen Ordner
git init

# Bestehendes Projekt kopieren
git clone https://github.com/expressjs/express.git

# Nur den neuesten Stand, ohne den ganzen Verlauf
git clone --depth 1 https://github.com/expressjs/express.git

git init legt einen versteckten Ordner .git an. Darin steckt das gesamte Gedächtnis des Projekts. git clone holt ein fremdes Repository vollständig, mit jedem Commit seit Beginn.

Der Unterschied zum flachen Klon mit --depth 1 ist messbar. Express.js komplett: 12 MB im .git-Ordner, Klonen in 0,97 Sekunden. Mit --depth 1: 392 KB und 0,54 Sekunden. Für einen CI-Server, der nur bauen will, ist der flache Klon perfekt. Zum Entwickeln nimmst du den vollen, sonst fehlen dir git log, git blame und git bisect die Daten.

Der tägliche Kreislauf: status, add, commit

Neunzig Prozent deiner Git-Zeit verbringst du in einer Schleife aus vier Befehlen: nachsehen, vormerken, speichern, hochladen.

git status: der wichtigste Befehl überhaupt

git status
git status -s      # Kurzform

Wenn du nur einen Git-Befehl auswendig lernst, dann diesen. Er sagt dir, auf welchem Branch du bist, welche Dateien geändert sind, welche vorgemerkt sind und welche Git noch gar nicht kennt. Er ist außerdem schnell: Im Express-Repository brauchte er 8 Millisekunden. Es gibt also keinen Grund, ihn nicht ständig zu tippen.

Die Kurzform -s zeigt zwei Spalten. Links der Stand in der Staging Area, rechts im Arbeitsverzeichnis. M heißt geändert, A hinzugefügt, ?? unbekannt.

git diff: was genau habe ich geändert?

git diff                 # Arbeitsverzeichnis gegen Staging Area
git diff --staged        # Staging Area gegen letzten Commit
git diff main..feature   # Zwei Branches vergleichen
git diff --stat HEAD~3   # Zusammenfassung der letzten drei Commits

Der häufigste Anfängerfehler mit git diff: Man hat Dateien schon mit git add vorgemerkt und wundert sich, dass git diff nichts mehr zeigt. Das ist korrekt so. Ohne Option vergleicht git diff nur, was noch nicht vorgemerkt ist. Für das Vorgemerkte brauchst du --staged.

git add: vormerken

git add index.html        # eine Datei
git add src/              # ein ganzer Ordner
git add -A                # alles, inklusive gelöschter Dateien
git add -p                # Änderungen stückweise auswählen

git add -p ist der unterschätzteste Befehl der ganzen Liste. Git zeigt dir jede Änderung einzeln und fragt, ob sie in den nächsten Commit soll. So kannst du aus einem chaotischen Arbeitsnachmittag zwei saubere Commits machen: einen für den Bugfix, einen für die neue Funktion.

git commit: speichern

git commit -m "Login-Formular validiert jetzt E-Mail-Adressen"
git commit -am "Tippfehler korrigiert"    # add + commit für bekannte Dateien
git commit --amend -m "Bessere Nachricht"  # letzten Commit ersetzen

-am ist praktisch, hat aber eine Falle: Es nimmt nur Dateien mit, die Git schon kennt. Eine neu angelegte Datei bleibt draußen. Das merkst du meistens erst, wenn der Kollege meldet, dass bei ihm etwas fehlt.

--amend ersetzt den letzten Commit. Wichtig zu verstehen: Es ändert ihn nicht, es baut einen neuen. In unserem Test wurde aus Commit 012eb1d nach dem Amend 18a7889. Eine neue ID heißt für Git ein anderer Commit. Solange du noch nicht gepusht hast, ist das egal. Danach erzeugt es Ärger, weil dein Verlauf und der auf dem Server nicht mehr zusammenpassen.

git log: der Verlauf

git log --oneline
git log --oneline --graph --all
git log -p datei.txt              # Änderungen einer Datei
git log --since="2 weeks ago"
git log --author="Fabian"
git shortlog -sn                  # Commits pro Person

git log ist überraschend schnell. Alle 6.182 Commits von Express.js listete git log --oneline in 40 Millisekunden auf. git shortlog -sn zeigte 399 Autorinnen und Autoren, an der Spitze TJ Holowaychuk mit 1.891 Commits. Mit --graph --all siehst du Branches als ASCII-Baum, was bei Merge-Problemen oft mehr hilft als jede grafische Oberfläche.

Branches: parallel arbeiten

Ein Branch ist in Git nur ein Zettel mit einer Commit-ID. Genau deshalb sind Branches so billig, und genau deshalb solltest du sie großzügig verwenden.

git branch, git switch, git checkout

git branch                    # alle lokalen Branches
git branch -a                 # inklusive Remote-Branches
git switch -c feature/login   # neuen Branch anlegen und wechseln
git switch main               # zurück zu main
git branch -d feature/login   # Branch löschen (nur wenn gemergt)
git branch -D experiment      # Branch löschen, auch ungemergt

Früher machte git checkout alles: Branches wechseln, Branches anlegen, Dateien zurücksetzen. Seit Git 2.23 gibt es dafür zwei getrennte Befehle: git switch für Branches und git restore für Dateien. checkout funktioniert weiterhin, ist aber mehrdeutig. In unserem Test haben wir einen Branch und eine Datei mit demselben Namen dev angelegt. git checkout dev muss dann raten, was gemeint ist. git switch dev kann nur einen Branch meinen. Für Einsteiger ist die Regel einfach: switch für Branches, restore für Dateien, checkout nur noch lesen können.

Übrigens schützt Git dich bei beiden Befehlen gleich gut: Mit ungespeicherten Änderungen an einer Datei, die auf dem Zielbranch anders aussieht, verweigern checkout und switch den Wechsel mit „Your local changes … would be overwritten“. Du verlierst dabei nichts.

git merge: zusammenführen

git switch main
git merge feature/login
git merge --abort          # bei Konflikten alles zurück

git merge holt die Commits eines anderen Branches in den aktuellen. Gibt es keine Überschneidungen, passiert das still. Haben beide Seiten dieselbe Zeile geändert, meldet Git einen Konflikt und markiert die Stelle in der Datei mit <<<<<<<, ======= und >>>>>>>. Du entscheidest, was stehen bleibt, machst git add und git commit. Und wenn dir das zu viel wird: git merge --abort stellt den Zustand vor dem Merge exakt wieder her. Das haben wir im Artikel Was ist Git? ausführlich durchgespielt.

git rebase: den Verlauf aufräumen

git switch feature/login
git rebase main             # eigene Commits auf den neuesten main-Stand setzen
git rebase -i HEAD~3        # die letzten drei Commits bearbeiten
git rebase --abort

rebase setzt deine Commits so um, als hättest du erst jetzt angefangen. Ergebnis: ein gerader Verlauf ohne Merge-Commits. Mit -i (interaktiv) kannst du Commits zusammenfassen, umbenennen oder umsortieren. In unserem Test haben wir drei Commits namens „fixup 4/5/6“ per squash zu einem einzigen gemacht. Der Verlauf schrumpfte von acht auf sechs Commits.

Die goldene Regel dazu: Nie Commits rebasen, die andere schon haben. Rebase erzeugt, wie --amend, neue Commit-IDs. Für deinen lokalen Feature-Branch vor dem ersten Push ist das ideal. Für main ist es tabu.

git cherry-pick: einen einzelnen Commit übernehmen

git cherry-pick a1b2c3d

Manchmal brauchst du aus einem Branch genau einen Commit, etwa einen Bugfix, ohne den Rest. cherry-pick kopiert ihn auf deinen aktuellen Branch. Auch hier entsteht eine Kopie mit neuer ID, kein Verweis.

Rückgängig machen: der Teil, vor dem alle Angst haben

Hier verwechseln Einsteiger am häufigsten Befehle. Dabei ist die Unterscheidung klar, wenn man fragt: Was will ich zurücknehmen, und hat das schon jemand anderes?

git restore: Änderungen an Dateien verwerfen

git restore index.html            # ungespeicherte Änderung verwerfen
git restore --staged index.html   # aus der Staging Area nehmen, Änderung bleibt
git restore --source=HEAD~2 app.js  # Datei auf Stand von vor zwei Commits

git restore ist der sicherste Rückgängig-Befehl, weil er nur Dateien anfasst, nie den Verlauf. Aber: Was du mit git restore datei verwirfst, war nie committet. Git hat davon keine Kopie. Das ist einer der wenigen Wege, in Git wirklich Arbeit zu verlieren.

git reset: den Branch zurücksetzen

git reset --soft HEAD~1    # Commit weg, Änderungen bleiben vorgemerkt
git reset HEAD~1           # Commit weg, Änderungen bleiben (nicht vorgemerkt)
git reset --hard HEAD~1    # Commit weg, Änderungen weg

Die drei Varianten haben wir nebeneinander getestet, jeweils auf einem Repository mit drei Commits, bei dem der letzte Commit die Datei f3 angelegt hatte:

Merkhilfe: --soft ist ein „Commit ungeschehen, Rest bleibt“, --hard ist ein „alles wie damals“. Alle drei verschieben den Branch, sie schreiben also Geschichte um. Für bereits gepushte Commits sind sie deshalb die falsche Wahl.

git revert: rückgängig machen, ohne Geschichte umzuschreiben

git revert a1b2c3d
git revert --no-edit HEAD

revert löscht nichts. Es erzeugt einen neuen Commit, der die Änderungen des alten exakt umkehrt. In unserem Test stieg die Zahl der Commits durch git revert von 103 auf 104, der Commit hieß automatisch Revert "feat". Das ist die richtige Wahl für alles, was schon auf dem Server liegt: Kollegen bekommen einfach einen weiteren Commit und müssen nichts reparieren.

Kleiner Stolperstein aus dem Test: git revert --no-edit HEAD -q endet mit einer Fehlermeldung, weil revert die Option -q schlicht nicht kennt. Andere Befehle wie commit oder stash pop kennen sie. Git ist da nicht konsistent.

Die Faustregel

git stash: Arbeit zwischenlagern

git stash                 # Änderungen beiseitelegen
git stash -u              # inklusive neuer, unbekannter Dateien
git stash list
git stash pop             # zurückholen und Stash löschen
git stash apply           # zurückholen, Stash behalten
git stash drop

Der klassische Fall: Du bist mitten in einer Funktion, und plötzlich muss ein Bugfix auf main. git stash räumt deinen Tisch ab, du wechselst, fixt, kommst zurück und holst alles mit git stash pop wieder hervor.

Die Falle haben wir im Test direkt gesehen. Nach einem einfachen git stash zeigte git status noch immer ?? neu.txt. Neue Dateien, die Git noch nicht kennt, nimmt git stash ohne Option nicht mit. Sie bleiben einfach liegen und landen beim Branchwechsel womöglich im falschen Commit. Erst git stash -u hat die Datei mit eingepackt, danach war sie aus dem Ordner verschwunden und kam mit pop zurück. Wer sich das nicht merken will, setzt sich einen Alias (siehe unten).

git clean: unbekannte Dateien löschen

git clean -n    # nur anzeigen, was gelöscht würde
git clean -fd   # wirklich löschen, inklusive Ordner

git clean löscht Dateien, die Git nicht verfolgt: Build-Reste, temporäre Dateien. Es gibt dafür keinen Papierkorb und kein Reflog. Deshalb immer zuerst -n (dry run). In unserem Test meldete es ordentlich „Would remove a.tmp“ und „Would remove b.tmp“, ohne etwas anzufassen.

git rm —cached: eine Datei nicht mehr verfolgen

git rm --cached .env
echo ".env" >> .gitignore
git commit -m ".env nicht mehr versionieren"

Damit hört Git auf, die Datei zu verfolgen, sie bleibt aber auf deiner Festplatte. Was viele nicht wissen: Die Datei bleibt im Verlauf. Im Test zeigte git log --all -- .env danach weiterhin den Commit, mit dem sie hinzugefügt wurde. Wer einmal ein Passwort committet hat, muss es deshalb als verbrannt betrachten und ändern. git rm --cached ist Aufräumen, keine Schadensbegrenzung.

Zusammenarbeit: remote, push, pull, fetch

Sobald ein zweiter Mensch oder ein Server ins Spiel kommt, brauchst du die Remote-Befehle.

git remote: wohin gehört das Repository?

git remote -v
git remote add origin git@github.com:name/projekt.git
git remote set-url origin git@github.com:name/neu.git

origin ist nur ein Spitzname für eine URL, Konvention, aber kein Zwang. Für den Zugriff per SSH brauchst du einen Schlüssel. Wie das geht, steht in unserer Anleitung SSH-Key erstellen.

git push

git push                        # aktuellen Branch hochladen
git push -u origin feature/x    # ersten Push eines neuen Branches, mit Verknüpfung
git push --tags
git push --force-with-lease     # vorsichtiges Überschreiben

-u brauchst du nur beim ersten Push eines Branches. Danach weiß Git, wohin der Branch gehört, und ein einfaches git push reicht.

—force vs. —force-with-lease: unser wichtigster Test

Wenn du einen bereits gepushten Commit mit --amend oder rebase umgeschrieben hast, lehnt der Server einen normalen Push ab. Die Versuchung heißt git push --force. Das überschreibt den Server-Stand blind, auch wenn ein Kollege in der Zwischenzeit etwas hochgeladen hat. Dessen Arbeit ist dann auf dem Server weg.

--force-with-lease gilt als die sichere Alternative: Git überschreibt nur, wenn der Server noch so aussieht, wie du ihn zuletzt gesehen hast. Das haben wir nachgestellt, mit einem lokalen Server-Repository und zwei Klonen:

1. Kollege pusht einen neuen Commit.
2. Wir ändern unseren letzten Commit mit --amend und versuchen git push --force-with-lease.
3. Ergebnis: ! [rejected] master -> master (stale info). Gut, der Schutz greift.
4. Dann machen wir, was man bei Push-Problemen reflexhaft tut: git fetch.
5. Erneut git push --force-with-lease: + f214804...60af982 HEAD -> master (forced update). Der Commit des Kollegen ist auf dem Server überschrieben.

Der Schutz von --force-with-lease vergleicht nur mit dem Stand, den dein letzter fetch gesehen hat. Ein fetch „bestätigt“ den fremden Commit, ohne dass du ihn je angesehen hast. Seit Git 2.30 gibt es dafür --force-if-includes, das zusätzlich prüft, ob der fremde Stand wirklich in deinem lokalen Verlauf steckt. Auch das haben wir geprüft: Nach demselben fetch lehnte git push --force-with-lease --force-if-includes ab, mit ! [rejected] (remote ref updated since checkout). Unsere Empfehlung:

git push --force-with-lease --force-if-includes

Und noch besser: Auf main gar nicht forcen, sondern dort Force-Pushes auf GitHub oder GitLab per Branch-Schutz ganz verbieten.

git fetch vs. git pull

git fetch                # neue Commits holen, nichts ändern
git pull                 # fetch + merge
git pull --rebase        # fetch + rebase

git fetch ist risikofrei. Es lädt neue Commits herunter und aktualisiert origin/main, deine Dateien bleiben unberührt. git pull macht danach noch einen Merge oder Rebase. Im Test hatten Server und lokaler Branch unterschiedliche Commits. git pull lud zwar herunter, blieb dann aber stehen mit dem Hinweis „You have divergent branches and need to specify how to reconcile them“. Git will, dass du dich einmal entscheidest: Merge (pull.rebase false) oder Rebase (pull.rebase true). Darum steht die Einstellung oben im Abschnitt Einrichtung.

git tag: Versionen markieren

git tag v1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0

Tags sind Branches, die sich nie bewegen. Express.js hat 306 davon, für jede veröffentlichte Version einen. Tags werden bei git push nicht automatisch mit hochgeladen, das vergisst man gern.

Detektiv- und Notfall-Befehle

Diese Befehle brauchst du selten. Aber wenn du sie brauchst, sparen sie Stunden.

git reflog: der Rettungsanker

git reflog
git reset --hard HEAD@{2}

Jedes Mal, wenn sich HEAD bewegt, also bei Commit, Wechsel, Reset, Rebase oder Cherry-Pick, schreibt Git einen Eintrag ins Reflog. In unserem kleinen Testrepository waren es nach einer Stunde Herumprobieren 120 Einträge. Wer versehentlich git reset --hard getippt hat, findet hier den alten Stand und holt ihn mit einem zweiten Reset zurück. Das Reflog ist lokal und hält standardmäßig 90 Tage. Es rettet Commits, aber keine Änderungen, die nie committet wurden.

git bisect: den schuldigen Commit finden

git bisect start
git bisect bad              # aktueller Stand ist kaputt
git bisect good v1.0        # dieser Stand war noch gut
# … Git checkt die Mitte aus, du testest und sagst good oder bad …
git bisect reset

# oder automatisch mit einem Testbefehl:
git bisect run npm test

Bisect ist binäre Suche über deinen Verlauf. In unserem Test steckte ein Fehler in Commit 51 von 100. git bisect run mit einem einzeiligen Testskript fand ihn in 6 Schritten und 0,05 Sekunden. Bei 1.000 Commits wären es 10 Schritte, bei einer Million 20. Wenn „früher ging es doch noch“ dein Problem beschreibt, ist das der Befehl.

git blame: wer hat diese Zeile geschrieben?

git blame lib/application.js
git blame -L 40,60 lib/application.js

Der Name klingt nach Schuldzuweisung, gemeint ist Spurensuche. git blame zeigt für jede Zeile, in welchem Commit sie zuletzt geändert wurde. Die Datei lib/application.js von Express lief in 33 Millisekunden durch. Mit der Commit-ID gehst du dann zu git show und liest, warum die Zeile so ist.

git log -S: wann kam dieser Text ins Projekt?

git log -S "trust proxy" --oneline

Die sogenannte Spitzhacke durchsucht nicht die Commit-Nachrichten, sondern den Inhalt aller Änderungen. In Express fand sie 28 Commits, die die Zeichenkette „trust proxy“ hinzugefügt oder entfernt haben. Über alle 6.182 Commits hat das 0,38 Sekunden gedauert. Damit findest du auch Passwörter, die irgendwann committet und wieder gelöscht wurden, was zeigt, warum gelöschte Geheimnisse nicht sicher sind.

git show: einen Commit ansehen

git show a1b2c3d
git show HEAD~2:src/app.js     # Datei in altem Stand anzeigen

git gc: aufräumen

git gc
git count-objects -vH

Git packt seine Daten von selbst gelegentlich zusammen. Unser Testrepository hatte nach 100 Commits 320 lose Objekte und einen 2,2 MB großen .git-Ordner. Nach git gc waren es 264 KB, alles in einer Pack-Datei von 33 KB. Notwendig ist der manuelle Aufruf fast nie, aber es zeigt, wie effizient Git intern speichert.

Aliase: deine eigene Git Befehle Liste

Was du täglich tippst, darfst du abkürzen. Diese Aliase nutzen wir selbst:

git config --global alias.st "status -s"
git config --global alias.lg "log --oneline --graph --all --decorate"
git config --global alias.undo "reset --soft HEAD~1"
git config --global alias.save "stash push -u"
git config --global alias.pushf "push --force-with-lease --force-if-includes"

Danach reicht git lg für den Baum und git save für einen Stash, der auch neue Dateien mitnimmt. Damit ist die Falle aus dem Stash-Abschnitt dauerhaft erledigt.

Häufige Fehlermeldungen und der passende Befehl

Git in der Praxis: wo wir die Befehle wirklich nutzen

Auf unseren Servern liegt praktisch alles unter Git: Websites, Konfigurationsdateien, Deploy-Skripte. Der typische Tag sieht so aus: git status, git add -p, git commit, git push. Für Releases kommt git tag dazu, für Live-Systeme ein eigener Arbeitsbaum auf einem festen Tag, damit am Live-System niemand aus Versehen weiterentwickelt. Das ist der Grund, warum wir git switch --detach v2.1.0 öfter tippen als man denkt.

Für automatische Aufgaben auf dem Server, etwa nächtliche git pull-Läufe, kombinieren wir Git mit Cronjobs. Wie man die zuverlässig anlegt, steht in Cronjob erstellen. Und wer einen neuen Server von Grund auf aufsetzt, findet Git als einen der ersten Schritte in unserer Anleitung Linux-Server einrichten.

Eine Lektion, die wir hart gelernt haben: Git ist kein Backup. Ein git push auf denselben Server, auf dem auch das Arbeitsverzeichnis liegt, schützt vor keinem Festplattenausfall. Dafür gibt es die 3-2-1-Backup-Strategie.

Englischsprachig, aber sehr gut strukturiert: Conner Ardman geht in „Every GIT Command You’ll EVER Need“ (Mai 2026) die Befehle dieser Liste der Reihe nach durch. Ein gleichwertiges, aktuelles deutsches Video zum reinen Befehlsüberblick haben wir nicht gefunden.

Fazit: Welche Git Befehle muss man wirklich können?

Von den 165 Befehlen musst du am Anfang genau acht beherrschen: status, add, commit, log, switch, merge, push und pull. Damit arbeitest du sauber allein und im Team. Die nächste Stufe sind die Rückgängig-Befehle restore, revert, reset und stash, und hier lohnt es sich, den Unterschied wirklich verstanden zu haben, statt Befehle aus Foren zu kopieren. Ganz oben stehen reflog, bisect, blame und log -S: selten gebraucht, aber dann unbezahlbar.

Zwei Dinge aus unseren Tests würden wir jedem mitgeben. Erstens: git stash ohne -u lässt neue Dateien liegen. Zweitens: --force-with-lease schützt nur bis zum nächsten fetch, also lieber gleich --force-if-includes dazunehmen. Beides steht in kaum einer Git Befehle Liste, und beides kann Arbeit kosten.

Speichere dir die Tabelle oben als Lesezeichen. Nach ein paar Wochen brauchst du sie nicht mehr.

Häufige Fragen zur Git Befehle Liste

Welche Git Befehle braucht man am häufigsten?

git status, git add, git commit, git push, git pull und git switch. Mit diesen sechs erledigst du den Großteil der täglichen Arbeit. git log und git diff kommen zum Nachsehen dazu.

Wie viele Git Befehle gibt es?

git help -a listet in Git 2.43 genau 165 Befehle auf. Viele davon sind interne Hilfsbefehle („plumbing“), die man nie direkt verwendet. Für den Alltag reichen 20 bis 40.

Was ist der Unterschied zwischen git reset und git revert?

git reset verschiebt den Branch auf einen älteren Commit und schreibt damit den Verlauf um. git revert erzeugt einen neuen Commit, der die Änderungen eines alten umkehrt, und lässt den Verlauf intakt. Für bereits gepushte Commits nimmst du revert, für lokale reset.

Was ist der Unterschied zwischen git fetch und git pull?

git fetch lädt neue Commits vom Server herunter, verändert aber weder deine Dateien noch deinen Branch. git pull macht zusätzlich einen Merge oder Rebase, bringt die neuen Commits also direkt in deine Arbeit.

Soll ich git checkout oder git switch verwenden?

Für Branches git switch, für Dateien git restore. Beide gibt es seit Git 2.23 und sie sind eindeutiger als das alte git checkout, das beides gleichzeitig konnte und bei gleichnamigen Branches und Dateien raten muss.

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

Wenn er noch nicht gepusht ist: git reset --soft HEAD~1. Die Änderungen bleiben vorgemerkt, nur der Commit ist weg. Wenn du nur die Nachricht ändern willst: git commit --amend. Wenn er schon auf dem Server liegt: git revert HEAD.

Wie hole ich einen gelöschten Commit zurück?

Mit git reflog die ID des alten Stands suchen und dann git reset --hard <id> oder git switch -c rettung <id>. Das Reflog hält Einträge standardmäßig 90 Tage, aber nur lokal auf deinem Rechner.

Nimmt git stash auch neue Dateien mit?

Nein, nicht ohne Option. Ein einfaches git stash speichert nur Änderungen an Dateien, die Git schon kennt. Neue Dateien bleiben im Ordner liegen. Mit git stash -u werden sie mit eingepackt.

Ist git push —force-with-lease sicher?

Sicherer als --force, aber nicht narrensicher. Es vergleicht nur mit dem Stand deines letzten git fetch. Wer vorher fetch ausführt, überschreibt fremde Commits trotzdem, das haben wir nachgestellt. Mit --force-if-includes zusätzlich ist der Schutz deutlich besser.

Gibt es eine Git Befehle Liste als PDF?

Die offizielle Referenz ist git help <befehl> direkt im Terminal oder die Dokumentation auf git-scm.com. GitHub bietet ein kostenloses Cheat Sheet als PDF an. Unsere Tabelle oben kannst du über die Druckfunktion des Browsers als PDF speichern.

Brauche ich die Kommandozeile oder reicht eine grafische Oberfläche?

Für den Alltag reicht eine Oberfläche wie die Git-Integration in VS Code oder GitHub Desktop. Trotzdem lohnt es sich, die Befehle einmal im Terminal zu lernen: Jede Oberfläche ruft im Hintergrund genau diese Befehle auf, und Fehlermeldungen beziehen sich auf sie.