Die 60 wichtigsten Git-Kommandos und ihre Bedeutung

Git-Kommandos helfen dir, Änderungen an Dateien nachzuvollziehen, Arbeit in Branches zu trennen und Ergebnisse mit anderen zu teilen. Die bisherige Liste auf dieser Seite endete bei Nummer 58 mitten im Satz. Hier findest du 60 vollständige, nach Aufgaben geordnete Befehlsbeispiele – vom ersten Commit bis zur Fehlersuche.

Du musst nicht alle 60 Git-Kommandos auswendig lernen. Für den Alltag reichen zunächst git status, git add, git commit, git log, git fetch und git push. Die übrigen Befehle sind ein Nachschlagewerk. Beispiele mit main setzen voraus, dass dein Hauptbranch so heißt; in deinem Repository kann er anders heißen.

Vor dem ersten Commit: Arbeitsverzeichnis, Staging Area und Repository

Git unterscheidet drei Zustände: Im Arbeitsverzeichnis bearbeitest du Dateien. Mit git add wählst du Änderungen für den nächsten Commit in der Staging Area aus. git commit speichert diesen Stand im lokalen Repository. Erst git push überträgt Commits an ein entferntes Repository. git status zeigt dir jederzeit, wo eine Änderung gerade liegt.

Git-Kommandos für Einrichtung und tägliche Arbeit (1–15)

1. git --version zeigt die installierte Git-Version. So prüfst du, ob Git im Terminal erreichbar ist.
2. git config --global user.name "Dein Name" legt deinen Namen für künftige Commits fest. Der Wert ist Commit-Metadatum, keine Anmeldung beim Hostingdienst.
3. git config --global user.email "du@example.com" setzt die E-Mail-Adresse für künftige Commits. Verwende die Adresse, die du für das Projekt vorgesehen hast.
4. git config --list --show-origin zeigt aktive Einstellungen und die Datei, aus der sie stammen. Das hilft bei widersprüchlichen lokalen und globalen Werten.
5. git init -b main erstellt im aktuellen Ordner ein neues Repository mit dem Startbranch main. Für ein bereits vorhandenes Remote-Repository nutzt du stattdessen git clone.
6. git clone https://example.com/team/projekt.git kopiert ein bestehendes Repository samt Historie in einen neuen lokalen Ordner. Ersetze die Beispieladresse durch die echte Repository-URL.
7. git status zeigt den aktuellen Branch sowie geänderte, vorgemerkte und nicht verfolgte Dateien. Vor einem Commit ist dies der wichtigste Kontrollblick.
8. git add README.md nimmt den aktuellen Stand dieser Datei in die Staging Area auf. Spätere Änderungen an derselben Datei musst du bei Bedarf erneut hinzufügen.
9. git add -p lässt dich einzelne Änderungsblöcke für den nächsten Commit auswählen. Das ist nützlich, wenn eine Datei mehrere unabhängige Änderungen enthält.
10. git diff zeigt Änderungen im Arbeitsverzeichnis, die noch nicht gestaged sind. Neue, noch nicht verfolgte Dateien erscheinen darin nicht.
11. git diff --cached zeigt die Änderungen, die bereits für den nächsten Commit vorgemerkt sind. --staged ist ein gleichwertiger Optionsname.
12. git commit -m "Dokumentation ergänzen" speichert die gestagten Änderungen als lokalen Commit. Eine Nachricht sollte knapp beschreiben, was sich geändert hat.
13. git commit --amend ersetzt den letzten Commit, etwa um seine Nachricht oder frisch gestagte Änderungen zu korrigieren. Dadurch ändert sich seine Commit-ID; bei bereits veröffentlichten Commits ist Vorsicht nötig.
14. git log --oneline --graph --decorate --all zeigt die Historie kompakt samt Branch- und Tag-Verweisen.
15. git show zeigt den letzten Commit und dessen Änderungen. Mit einer Commit-ID als Argument kannst du einen bestimmten Commit untersuchen.

Branches und Änderungen zusammenführen (16–27)

16. git branch listet lokale Branches auf. Ein Stern markiert den aktuell ausgecheckten Branch.
17. git switch -c feature/login erstellt den Branch feature/login und wechselt dorthin. Er wird vom aktuellen Commit abgezweigt.
18. git switch main wechselt zu einem bestehenden Branch. Wenn lokale Änderungen dabei überschrieben würden, verweigert Git den Wechsel normalerweise.
19. git branch -d feature/login löscht einen lokalen Branch nach abgeschlossener Arbeit. Git verweigert das Löschen normalerweise, wenn seine Änderungen noch nicht passend integriert wurden.
20. git merge feature/login integriert diesen Branch in den aktuell ausgecheckten Branch. Prüfe vor dem Befehl mit git status, wo du stehst.
21. git merge --abort bricht einen laufenden Merge nach Konflikten ab und versucht, den Zustand vor dem Merge wiederherzustellen.
22. git rebase main setzt die Commits des aktuellen Branches auf die Spitze von main. Dabei entstehen neue Commit-IDs. Rebase veröffentlichter, gemeinsam genutzter Branches nur nach Absprache.
23. git rebase --abort bricht einen noch laufenden Rebase ab, beispielsweise wenn die Konfliktlösung nicht wie erwartet gelingt.
24. git cherry-pick <commit-id> übernimmt die Änderung eines bestimmten Commits in den aktuellen Branch und erzeugt dort einen neuen Commit.
25. git cherry-pick --abort bricht einen laufenden Cherry-Pick mit Konflikten ab.
26. git tag -a v1.0.0 -m "Version 1.0.0" markiert den aktuellen Commit mit einem kommentierten Tag. Tags eignen sich beispielsweise für Releases.
27. git tag --list listet lokale Tags auf. Ein lokaler Tag wird erst mit einem passenden Push-Befehl auf den Remote übertragen.

Git-Kommandos für Remotes und Zusammenarbeit (28–36)

28. git remote -v zeigt die Namen und URLs der konfigurierten Remotes. origin ist ein üblicher Name, aber keine Pflicht.
29. git remote add origin https://example.com/team/projekt.git fügt einem lokalen Repository einen Remote hinzu. Bei einem geklonten Repository ist origin meist schon vorhanden.
30. git fetch origin lädt neue Remote-Commits und Referenzen, ohne sie automatisch in deinen aktuellen Branch zu integrieren.
31. git pull --ff-only holt Änderungen für den konfigurierten Upstream-Branch und integriert sie nur, wenn ein Fast-Forward möglich ist. Andernfalls stoppt der Befehl, damit du die Abweichung bewusst klärst.
32. git push -u origin main veröffentlicht den lokalen Branch main auf origin und richtet ihn als Upstream ein. Verwende den tatsächlichen Branch-Namen deines Projekts.
33. git push origin feature/login veröffentlicht den genannten lokalen Branch. Ein normaler Push überschreibt keine abweichende Remote-Historie.
34. git ls-remote origin zeigt Referenzen und Commit-IDs auf dem Remote, ohne dessen Änderungen in deine lokalen Branches zu übernehmen.
35. git diff main...feature/login zeigt die Änderungen auf feature/login seit dem gemeinsamen Ausgangspunkt mit main. Die drei Punkte sind hier wichtig.
36. git log main..feature/login --oneline listet Commits, die von feature/login aus erreichbar sind, von main aber noch nicht.

Zwischenstände sichern und Fehler rückgängig machen (37–49)

Hier lohnt ein zweiter Blick auf git status. restore, reset und revert lösen unterschiedliche Probleme: restore behandelt Dateien, reset kann Branch-Zeiger oder Staging Area ändern, und revert macht einen Commit durch einen neuen Commit rückgängig. Die Git-Dokumentation erklärt diese Unterscheidung.

37. git stash push -m "Zwischenstand" legt verfolgte lokale Änderungen vorübergehend ab. Neue, nicht verfolgte Dateien werden standardmäßig nicht mitgenommen; dafür gibt es -u.
38. git stash list zeigt gespeicherte Stashes an. So siehst du, welche Zwischenstände noch vorhanden sind.
39. git stash pop wendet den neuesten Stash an und entfernt ihn bei erfolgreicher Anwendung aus der Liste. Konflikte musst du gegebenenfalls lösen.
40. git stash apply wendet den neuesten Stash an, behält den Stash-Eintrag aber für eine spätere Wiederverwendung.
41. git restore -- README.md verwirft nicht gestagte Änderungen an dieser verfolgten Datei. Achtung: Die verworfenen Änderungen können verloren sein.
42. git restore --staged -- README.md nimmt die Datei aus der Staging Area, ohne ihre Änderungen im Arbeitsverzeichnis zu verwerfen.
43. git revert <commit-id> erzeugt einen neuen Commit, der die Wirkung des genannten Commits umkehrt. Für bereits veröffentlichte Änderungen ist das oft nachvollziehbarer als ein Reset.
44. git reset --soft HEAD~1 nimmt den letzten lokalen Commit aus der Branch-Historie zurück; seine Änderungen bleiben gestaged. Vermeide das auf gemeinsam genutzten, veröffentlichten Branches.
45. git reset --mixed HEAD~1 nimmt den letzten lokalen Commit zurück und entfernt seine Änderungen aus der Staging Area. Die Änderungen bleiben im Arbeitsverzeichnis.
46. git clean -nd zeigt unverfolgte Dateien und Verzeichnisse an, die ein anschließendes git clean -fd entfernen würde. Beginne immer mit dieser Vorschau.
47. git clean -fd entfernt unverfolgte Dateien und Verzeichnisse. Achtung: Das kann nicht eingecheckte Arbeit dauerhaft löschen; prüfe die Vorschau und den aktuellen Pfad zuerst.
48. git reflog zeigt lokale Bewegungen von HEAD und Referenzen. Damit findest du mitunter einen Commit wieder, der im normalen Log nicht mehr sichtbar ist. Reflog-Einträge sind nicht dauerhaft garantiert.
49. git restore --source=<commit-id> -- README.md holt den Stand einer Datei aus einem bestimmten Commit ins Arbeitsverzeichnis. Das ändert den aktuellen Branch-Zeiger nicht; vorhandene ungestagte Änderungen an der Datei können überschrieben werden.

Dateien untersuchen und größere Projekte verwalten (50–60)

50. git rm alte-datei.txt entfernt eine verfolgte Datei aus dem Arbeitsverzeichnis und merkt ihre Löschung für den nächsten Commit vor.
51. git mv alt.txt neu.txt benennt eine verfolgte Datei um und staged die Änderung. Git erkennt Umbenennungen anhand des Inhalts; es speichert sie nicht als eigenes dauerhaftes Objekt.
52. git grep -n "TODO" sucht in verfolgten Dateien nach dem Text TODO und zeigt Zeilennummern an.
53. git blame -L 1,20 -- README.md zeigt für die ersten 20 Zeilen, welcher Commit sie zuletzt geändert hat. Das ist ein Ausgangspunkt für Nachfragen, kein Beweis für die Ursache eines Fehlers.
54. git bisect start beginnt eine binäre Suche nach dem Commit, der einen reproduzierbaren Fehler eingeführt hat.
55. git bisect bad HEAD markiert den aktuellen Commit im laufenden Bisect als fehlerhaft.
56. git bisect good <commit-id> markiert einen älteren, nachweislich funktionierenden Commit. Git wählt danach Teststände zwischen „gut“ und „schlecht“ aus; bewerte jeden mit git bisect good oder git bisect bad.
57. git bisect reset beendet die Suche und kehrt zum vorherigen Branch zurück.
58. git worktree add -b fix/bug ../fix-bug erstellt einen zweiten Arbeitsordner samt neuem Branch. So kannst du parallel arbeiten, ohne den aktuellen Ordner umzuschalten.
59. git submodule update --init --recursive initialisiert und aktualisiert die im Projekt eingetragenen Submodule einschließlich verschachtelter Submodule.
60. git fsck --full prüft die Git-Objektdatenbank auf Konsistenz. Der Befehl ist eher für Fehlersuche als für die tägliche Arbeit gedacht.

Ein sinnvoller Ablauf für den ersten eigenen Branch

Nach der Einrichtung kannst du einen typischen Arbeitsablauf mit wenigen Befehlen abdecken:

git switch -c feature/login
git status
git diff
git add -p
git diff --cached
git commit -m "Login-Formular ergänzen"
git fetch origin
git push -u origin feature/login

git add -p lässt dich gezielt Änderungen auswählen. Sind alle Änderungen für denselben Commit gedacht, kannst du stattdessen passende Dateien einzeln mit git add datei vormerken. Prüfe vor jedem Push noch einmal git status und die Commit-Historie.

Häufige Fragen zu Git-Kommandos

Was ist der Unterschied zwischen git fetch und git pull?

git fetch aktualisiert deine Sicht auf das Remote-Repository, ohne den aktuellen Branch zu integrieren. git pull holt Änderungen und versucht anschließend, sie in den aktuellen Branch zu integrieren. Wenn du erst prüfen möchtest, was sich geändert hat, beginne mit git fetch.

Wann sollte ich git push –force verwenden?

Im normalen Team-Workflow möglichst nicht. Ein erzwungener Push kann Remote-Commits überschreiben. Falls ein ausdrücklich abgestimmter History-Rewrite nötig ist, lies die Dokumentation zu --force-with-lease und prüfe den konkreten Branch. Auch diese Option ersetzt keine Abstimmung im Team.

Kann Git gelöschte Dateien immer wiederherstellen?

Nein. Git kann versionierte Dateistände aus Commits wiederherstellen. Unverfolgte Dateien, die beispielsweise mit git clean -fd gelöscht wurden, liegen nicht automatisch in der Git-Historie. Ein Backup bleibt wichtig.

Fazit

Die 60 Git-Kommandos sind nach Arbeitsschritten geordnet, damit du den passenden Befehl schneller findest. Starte mit Status, Diff, Add und Commit; ergänze danach Branches und Remotes. Für jede Rücknahme gilt: Prüfe zuerst, ob die Änderung nur lokal vorliegt oder bereits veröffentlicht wurde. Die vollständige Syntax und weitere Beispiele stehen in der offiziellen Git-Referenz.