Übersicht

git checkout [<branch>]
git checkout -b <new-branch> [<start-point>]
git checkout [<tree-ish>] -- <file>...

Beschreibung

Der git checkout-Befehl tut historisch zwei nicht zusammenhängende Dinge: Branches wechseln und Dateien wiederherstellen. Wegen dieser Überladung führte modernes Git git switch für Branch-Operationen und git restore für Datei-Operationen ein. git checkout funktioniert weiterhin und bleibt beliebt, aber neue Nutzer werden ermutigt, die neueren aufgeteilten Befehle zu lernen.

Wenn ein Branch-Name übergeben wird, bewegt git checkout HEAD auf diesen Branch und aktualisiert den Working Tree. Mit einem Pfad-Argument überschreibt er die Working-Tree-Datei mit der Version aus dem Index (oder aus einem angegebenen Commit). Das -b-Flag erstellt einen neuen Branch und wechselt in einem Schritt zu ihm.

Im täglichen Einsatz integriert sich git checkout eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git checkout --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.

Zu verstehen, wie git checkout mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git checkout hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
-b <name>	Erstellt einen neuen Branch und wechselt zu ihm.
-B <name>	Erstellt oder setzt einen Branch zurück und wechselt zu ihm.
--track	Richtet Tracking für einen Remote-Branch ein.
--detach	Checkt einen Commit im Detached-HEAD-Zustand aus.
-- <path>	Behandelt folgende Argumente als Pfade, nicht als Branches.
-f, --force	Verwirft lokale Änderungen beim Wechseln.
-p, --patch	Wählt interaktiv Hunks zum Wiederherstellen aus.

Beispiele

git checkout main
    # Auf den main-Branch wechseln

    git checkout -b feature/api origin/develop
    # Einen neuen Branch erstellen, der origin/develop trackt

    git checkout HEAD -- src/config.js
    # Lokale Änderungen an einer einzelnen Datei verwerfen

    git checkout v1.2.3
    # Detached HEAD bei einem bestimmten Tag

Häufige Fehler

Das Ausführen von git checkout <file> überschreibt Ihre lokalen Bearbeitungen stillschweigend ohne Undo. Verwenden Sie stattdessen git restore — der Name ist klarer. Der Detached-HEAD-Zustand überrascht Anfänger: Dort gemachte Commits gehören zu keinem Branch und können verloren gehen, wenn Sie wegwechseln. Wenn Sie sie behalten wollen, erstellen Sie zuerst einen Branch.

Verwandte Befehle

git switch, git restore, git branch, git reset