Git

git-checkout zuletzt aktualisiert in 2.52.0

NAME

git-checkout - Zweige wechseln oder Arbeitskopiedateien wiederherstellen

SYNOPSIS

git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] --detach [<branch>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>]
git checkout <tree-ish> [--] <pathspec>…
git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>…
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…]

BESCHREIBUNG

git checkout hat zwei Hauptmodi

Zweige wechseln, mit git checkout <branch>
Eine andere Version einer Datei wiederherstellen, zum Beispiel mit git checkout <commit> <filename> oder git checkout <filename>

Siehe ARGUMENT DISAMBIGUATION unten, wie Git entscheidet, was zu tun ist.

git checkout [<branch>]

Wechselt zu <branch>. Dies setzt den aktuellen Zweig auf <branch> und aktualisiert die Dateien in Ihrem Arbeitsverzeichnis. Der Checkout schlägt fehl, wenn es unveränderte Änderungen an Dateien gibt, deren Inhalt sich zwischen <branch> und Ihrem aktuellen Commit unterscheidet. Unveränderte Änderungen bleiben ansonsten erhalten.

Wenn <branch> nicht gefunden wird, aber ein Tracking-Zweig auf genau einem Remote-System (nennen wir es <remote>) mit übereinstimmendem Namen existiert und --no-guess nicht angegeben ist, wird dies als äquivalent zu behandelt.

$ git checkout -b <branch> --track <remote>/<branch>

Das Ausführen von git checkout ohne Angabe eines Zweigs hat keine andere Auswirkung, als die Tracking-Informationen für den aktuellen Zweig auszugeben.

git checkout -b <new-branch> [<start-point>]

Erstellt einen neuen Zweig namens <new-branch>, startet ihn bei <start-point> (standardmäßig der aktuelle Commit) und checkt den neuen Zweig aus. Sie können die Optionen --track oder --no-track verwenden, um die Upstream-Tracking-Informationen des Zweigs festzulegen.

Dies schlägt fehl, wenn beim Auschecken von <new-branch> ein Fehler auftritt, zum Beispiel wenn das Auschecken des <start-point> Commits Ihre unveränderten Änderungen überschreiben würde.

git checkout -B <branch> [<start-point>]

Das Gleiche wie -b, nur dass der Zweig <branch> auf den Startpunkt zurückgesetzt wird, falls er bereits existiert, anstatt mit einem Fehler abzubrechen.

git checkout --detach [<branch>]

git checkout [--detach] <commit>

Das Gleiche wie git checkout <branch>, nur dass anstatt HEAD auf den Zweig zu zeigen, HEAD auf die Commit-ID zeigt. Siehe den Abschnitt "DETACHED HEAD" unten für weitere Details.

Das Weglassen von <branch> löst HEAD am Ende des aktuellen Zweigs.

git checkout <tree-ish> [--] <pathspec>...

git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]

Ersetzt die angegebenen Dateien und/oder Verzeichnisse durch die Version aus dem gegebenen Commit oder Tree und fügt sie dem Index hinzu (auch bekannt als "Staging-Bereich").

Zum Beispiel ersetzt git checkout main file.txt die Datei file.txt durch die Version aus main.

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]

Ersetzt die angegebenen Dateien und/oder Verzeichnisse durch die Version aus dem Index.

Wenn Sie beispielsweise einen Commit auschecken, file.txt bearbeiten und dann entscheiden, dass diese Änderungen ein Fehler waren, verwirft git checkout file.txt alle nicht gestageten Änderungen an file.txt.

Dies schlägt fehl, wenn die Datei einen Merge-Konflikt hat und Sie noch nicht git add file.txt (oder etwas Äquivalentes) ausgeführt haben, um sie als gelöst zu markieren. Sie können -f verwenden, um die nicht gemergten Dateien zu ignorieren, anstatt abzubrechen, --ours oder --theirs verwenden, um sie durch die Version von einer bestimmten Seite des Merges zu ersetzen, oder -m verwenden, um sie durch das ursprüngliche Konfliktergebnis zu ersetzen.

git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]

Dies ist ähnlich wie die beiden vorherigen Modi, erlaubt Ihnen jedoch die Verwendung der interaktiven Schnittstelle, um die "Diff"-Ausgabe anzuzeigen und auszuwählen, welche Hunks im Ergebnis verwendet werden sollen. Die Beschreibung der Option --patch finden Sie unten.

OPTIONEN

-q

--quiet

Leise, unterdrückt Feedback-Meldungen.

--progress

--no-progress

Der Fortschritt wird standardmäßig im Standardfehlerstrom gemeldet, wenn er an ein Terminal angeschlossen ist, es sei denn, --quiet ist angegeben. Diese Flagge aktiviert die Fortschrittsanzeige auch dann, wenn sie nicht an ein Terminal angeschlossen ist, unabhängig von --quiet.

-f

--force

Beim Wechseln von Zweigen wird fortgefahren, auch wenn der Index oder der Arbeitsbaum vom HEAD abweichen und auch wenn nicht verfolgte Dateien im Weg sind. Dies wird verwendet, um lokale Änderungen und alle nicht verfolgten Dateien oder Verzeichnisse, die im Weg sind, zu verwerfen.

Beim Auschecken von Pfaden aus dem Index wird bei nicht gemergten Einträgen nicht abgebrochen; stattdessen werden nicht gemergte Einträge ignoriert.

--ours

--theirs

Beim Auschecken von Pfaden aus dem Index wird für nicht gemergte Pfade Stage #2 (ours) oder #3 (theirs) ausgecheckt.

Beachten Sie, dass während git rebase und git pull --rebase, ours und theirs vertauscht erscheinen können; --ours gibt die Version aus dem Zweig an, auf den die Änderungen rebased werden, während --theirs die Version aus dem Zweig angibt, der Ihre Arbeit enthält, die rebased wird.

Dies liegt daran, dass rebase in einem Workflow verwendet wird, der den Verlauf des Remotes als den gemeinsamen kanonischen Verlauf betrachtet und die auf dem Zweig durchgeführte Arbeit als Drittanbieterarbeit betrachtet, die integriert werden soll, und Sie vorübergehend die Rolle des Bewahrers des kanonischen Verlaufs während des Rebase übernehmen. Als Bewahrer des kanonischen Verlaufs müssen Sie den Verlauf vom Remote als ours (d. h. "unser gemeinsamer kanonischer Verlauf") betrachten, während das, was Sie auf Ihrem Seiten-Zweig getan haben, als theirs (d. h. "Arbeit eines Beitragszahlers darauf") betrachtet wird.

-b <new-branch>

Erstellt einen neuen Zweig namens <new-branch>, startet ihn bei <start-point> und checkt den resultierenden Zweig aus; siehe git-branch[1] für Details.

-B <new-branch>

Das Gleiche wie -b, nur dass der Zweig <branch> auf den Startpunkt zurückgesetzt wird, falls er bereits existiert, anstatt mit einem Fehler abzubrechen.

-t

--track[=(direct|inherit)]

Beim Erstellen eines neuen Zweigs wird die "Upstream"-Konfiguration eingerichtet. Siehe --track in git-branch[1] für Details. Als Bequemlichkeit impliziert --track ohne -b die Erstellung eines Zweigs.

Wenn keine -b Option gegeben wird, wird der Name des neuen Zweigs vom Remote-Tracking-Zweig abgeleitet, indem der lokale Teil der für das entsprechende Remote konfigurierten Ref-Spezifikation betrachtet und dann der Anfangsteil bis zum "*" gestrippt wird. Dies würde uns sagen, hack als lokalen Zweig zu verwenden, wenn wir von origin/hack (oder remotes/origin/hack, oder sogar refs/remotes/origin/hack) verzweigen. Wenn der angegebene Name keinen Schrägstrich hat oder die obige Vermutung einen leeren Namen ergibt, wird die Vermutung abgebrochen. Sie können in einem solchen Fall explizit einen Namen mit -b angeben.

--no-track

Richtet keine "Upstream"-Konfiguration ein, auch wenn die Konfigurationsvariable branch.autoSetupMerge auf true gesetzt ist.

--guess

--no-guess

Wenn <branch> nicht gefunden wird, aber ein Tracking-Zweig auf genau einem Remote-System (nennen wir es <remote>) mit übereinstimmendem Namen existiert, wird dies als äquivalent zu behandelt.

$ git checkout -b <branch> --track <remote>/<branch>

Wenn der Zweig auf mehreren Remotes existiert und eines davon durch die Konfigurationsvariable checkout.defaultRemote benannt ist, wird dieses für die Zweideutigkeit verwendet, auch wenn <branch> nicht eindeutig über alle Remotes hinweg ist. Setzen Sie es z. B. auf checkout.defaultRemote=origin, um immer Remote-Zweige von dort auszuchecken, wenn <branch> mehrdeutig, aber auf dem origin-Remote vorhanden ist. Siehe auch checkout.defaultRemote in git-config[1].

--guess ist das Standardverhalten. Verwenden Sie --no-guess, um es zu deaktivieren.

Das Standardverhalten kann über die Konfigurationsvariable checkout.guess eingestellt werden.

-l

Erstellt das Reflog des neuen Zweigs; siehe git-branch[1] für Details.

-d

--detach

Anstatt einen Zweig zum Arbeiten auszuchecken, wird ein Commit zum Überprüfen und für experimentelle, verwerfbare Zwecke ausgecheckt. Dies ist das Standardverhalten von git checkout <commit>, wenn <commit> kein Zweigname ist. Siehe den Abschnitt "DETACHED HEAD" unten für Details.

--orphan <new-branch>

Erstellt einen neuen ungeborenen Zweig namens <new-branch>, der bei <start-point> beginnt und zu dem gewechselt wird. Der erste Commit, der in diesem neuen Zweig erstellt wird, hat keine Eltern und ist die Wurzel einer neuen Historie, die vollständig von allen anderen Zweigen und Commits getrennt ist.

Der Index und der Arbeitsbaum werden so angepasst, als ob Sie zuvor git checkout <start-point> ausgeführt hätten. Dies ermöglicht Ihnen, eine neue Historie zu beginnen, die einen Satz von Pfaden aufzeichnet, der dem von <start-point> ähnelt, indem Sie einfach git commit -a ausführen, um den Wurzel-Commit zu erstellen.

Dies kann nützlich sein, wenn Sie den Baum eines Commits veröffentlichen möchten, ohne dessen vollständige Historie preiszugeben. Sie könnten dies tun, um einen Open-Source-Zweig eines Projekts zu veröffentlichen, dessen aktueller Baum "sauber" ist, dessen vollständige Historie jedoch proprietäre oder anderweitig eingeschränkte Code-Teile enthält.

Wenn Sie eine getrennte Historie starten möchten, die einen Satz von Pfaden aufzeichnet, der sich vollständig von dem von <start-point> unterscheidet, sollten Sie den Index und den Arbeitsbaum sofort nach dem Erstellen des Orphan-Zweigs löschen, indem Sie git rm -rf . vom obersten Verzeichnis des Arbeitsbaums ausführen. Danach sind Sie bereit, Ihre neuen Dateien vorzubereiten, den Arbeitsbaum neu zu füllen, indem Sie sie von woanders kopieren, ein Tarball entpacken usw.

--ignore-skip-worktree-bits

Im Sparse-Checkout-Modus würde git checkout -- <path>... nur Einträge aktualisieren, die von <paths> und Sparse-Mustern in $GIT_DIR/info/sparse-checkout übereinstimmen. Diese Option ignoriert die Sparse-Muster und fügt alle Dateien in <path>... wieder hinzu.

-m

--merge

Beim Wechseln von Zweigen, wenn Sie lokale Änderungen an einer oder mehreren Dateien haben, die sich zwischen dem aktuellen Zweig und dem Zweig, zu dem Sie wechseln, unterscheiden, weigert sich der Befehl, die Zweige zu wechseln, um Ihre Änderungen im Kontext zu erhalten. Mit dieser Option wird jedoch ein Drei-Wege-Merge zwischen dem aktuellen Zweig, dem Inhalt Ihres Arbeitsbaums und dem neuen Zweig durchgeführt, und Sie sind auf dem neuen Zweig.

Wenn ein Merge-Konflikt auftritt, bleiben die Indexeinträge für die widersprüchlichen Pfade ungemerged, und Sie müssen die Konflikte auflösen und die gelösten Pfade mit git add (oder git rm, wenn der Merge zur Löschung des Pfads führen soll) markieren.

Beim Auschecken von Pfaden aus dem Index lässt diese Option zu, den konfliktbehafteten Merge in den angegebenen Pfaden neu zu erstellen. Diese Option kann nicht verwendet werden, wenn Pfade aus einem Tree-ish ausgecheckt werden.

Beim Wechseln von Zweigen mit --merge können gestagete Änderungen verloren gehen.

--conflict=<style>

Das Gleiche wie die Option --merge oben, aber ändert die Art und Weise, wie widersprüchliche Hunks dargestellt werden, und überschreibt die Konfigurationsvariable merge.conflictStyle. Mögliche Werte sind merge (Standard), diff3 und zdiff3.

-p

--patch

Interaktiv Hunks in der Differenz zwischen dem <tree-ish> (oder dem Index, wenn nicht angegeben) und dem Arbeitsbaum auswählen. Die ausgewählten Hunks werden dann umgekehrt auf den Arbeitsbaum angewendet (und wenn ein <tree-ish> angegeben wurde, auf den Index).

Das bedeutet, dass Sie git checkout -p verwenden können, um selektiv Bearbeitungen aus Ihrem aktuellen Arbeitsbaum zu verwerfen. Lesen Sie den Abschnitt "Interaktiver Modus" von git-add[1], um zu erfahren, wie Sie den --patch Modus bedienen.

Beachten Sie, dass diese Option standardmäßig den Overlay-Modus nicht verwendet (siehe auch --overlay) und derzeit den Overlay-Modus nicht unterstützt.

-U<n>

--unified=<n>

Generiert Diffs mit <n> Zeilen Kontext. Standard ist diff.context oder 3, wenn die Konfigurationsoption nicht gesetzt ist.

--inter-hunk-context=<n>

Zeigt den Kontext zwischen Diff-Hunks bis zur angegebenen Anzahl von <n> Zeilen an und fasst so nahe beieinander liegende Hunks zusammen. Standard ist diff.interHunkContext oder 0, wenn die Konfigurationsoption nicht gesetzt ist.

--ignore-other-worktrees

git checkout lehnt ab, wenn der gewünschte Zweig bereits ausgecheckt ist oder anderweitig von einem anderen Worktree verwendet wird. Diese Option veranlasst ihn, den Zweig trotzdem auszuchecken. Mit anderen Worten, der Zweig kann von mehr als einem Worktree verwendet werden.

--overwrite-ignore

--no-overwrite-ignore

Ignorierte Dateien beim Wechseln von Zweigen stillschweigend überschreiben. Dies ist das Standardverhalten. Verwenden Sie --no-overwrite-ignore, um den Vorgang abzubrechen, wenn der neue Zweig ignorierte Dateien enthält.

--recurse-submodules

--no-recurse-submodules

Die Verwendung von --recurse-submodules aktualisiert den Inhalt aller aktiven Submodule entsprechend dem im Superprojekt aufgezeichneten Commit. Wenn lokale Änderungen in einem Submodul überschrieben würden, schlägt der Checkout fehl, es sei denn, -f wird verwendet. Wenn nichts (oder --no-recurse-submodules) verwendet wird, werden die Arbeitsbäume der Submodule nicht aktualisiert. Genau wie bei git-submodule[1], wird dies HEAD des Submoduls lösen.

--overlay

--no-overlay

Im Standard-Overlay-Modus entfernt git checkout niemals Dateien aus dem Index oder dem Arbeitsbaum. Wenn --no-overlay angegeben wird, werden Dateien, die im Index und im Arbeitsbaum erscheinen, aber nicht im <tree-ish>, entfernt, um sie exakt mit <tree-ish> abzugleichen.

--pathspec-from-file=<file>

Pathspec wird in <file> anstelle von Kommandozeilenargumenten übergeben. Wenn <file> genau - ist, wird die Standardeingabe verwendet. Pathspec-Elemente werden durch LF oder CR/LF getrennt. Pathspec-Elemente können wie für die Konfigurationsvariable core.quotePath erklärt (siehe git-config[1]) in Anführungszeichen gesetzt werden. Siehe auch --pathspec-file-nul und global --literal-pathspecs.

--pathspec-file-nul

Nur relevant mit --pathspec-from-file. Pfadangaben werden durch ein NUL-Zeichen getrennt und alle anderen Zeichen werden wörtlich genommen (einschließlich Zeilenumbrüchen und Anführungszeichen).

<branch>

Zweig, der ausgecheckt werden soll; wenn er sich auf einen Zweig bezieht (d.h. ein Name, der nach Voranstellen von "refs/heads/" ein gültiger Ref ist), dann wird dieser Zweig ausgecheckt. Andernfalls, wenn er sich auf einen gültigen Commit bezieht, wird Ihr HEAD "detached" (losgelöst), und Sie befinden sich nicht mehr auf einem Zweig (siehe unten für Details).

Sie können die @{-N}-Syntax verwenden, um sich auf den N-ten zuletzt mit dem Vorgang "git checkout" ausgecheckten Zweig/Commit zu beziehen. Sie können auch - angeben, was eine Kurzform für @{-1} ist.

Als Sonderfall können Sie <rev-a>...<rev-b> als Kurzform für die Merge-Basis von <rev-a> und <rev-b> verwenden, wenn es genau eine Merge-Basis gibt. Sie können höchstens eine der Angaben <rev-a> und <rev-b> weglassen, in diesem Fall wird standardmäßig HEAD verwendet.

<new-branch>

Name für den neuen Zweig.

<start-point>

Der Name eines Commits, an dem der neue Zweig beginnen soll; siehe git-branch[1] für Details. Standardmäßig HEAD.

<tree-ish>

Tree, von dem ausgecheckt werden soll (wenn Pfade angegeben sind). Wenn nicht angegeben, wird der Index verwendet.

--

Interpretiere keine weiteren Argumente mehr als Optionen.

<pathspec>...

Begrenzt die von der Operation betroffenen Pfade.

Weitere Details finden Sie im Eintrag pfadspec in gitglossary[7].

DETACHED HEAD

HEAD bezieht sich normalerweise auf einen benannten Zweig (z. B. master). Jeder Zweig bezieht sich wiederum auf einen bestimmten Commit. Betrachten wir ein Repository mit drei Commits, einem davon mit einem Tag, und mit dem ausgecheckten Zweig master.

           HEAD (refers to branch 'master')
            |
            v
a---b---c  branch 'master' (refers to commit 'c')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

Wenn in diesem Zustand ein Commit erstellt wird, wird der Zweig aktualisiert, um auf den neuen Commit zu verweisen. Insbesondere erstellt git commit einen neuen Commit d, dessen Eltern Commit c ist, und aktualisiert dann den Zweig master, um auf den neuen Commit d zu verweisen. HEAD verweist weiterhin auf den Zweig master und verweist somit indirekt nun auf den Commit d.

$ edit; git add; git commit

               HEAD (refers to branch 'master')
                |
                v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

Es ist manchmal nützlich, einen Commit auschecken zu können, der sich nicht an der Spitze eines benannten Zweigs befindet, oder sogar einen neuen Commit zu erstellen, der nicht von einem benannten Zweig referenziert wird. Betrachten wir, was passiert, wenn wir Commit b auschecken (hier zeigen wir zwei Möglichkeiten, wie dies geschehen kann).

$ git checkout v2.0  # or
$ git checkout master^^

   HEAD (refers to commit 'b')
    |
    v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

Beachten Sie, dass unabhängig davon, welchen Checkout-Befehl wir verwenden, HEAD nun direkt auf Commit b verweist. Dies ist als "detached HEAD" Zustand bekannt. Es bedeutet einfach, dass HEAD auf einen bestimmten Commit verweist, im Gegensatz zum Verweisen auf einen benannten Zweig. Sehen wir uns an, was passiert, wenn wir einen Commit erstellen.

$ edit; git add; git commit

     HEAD (refers to commit 'e')
      |
      v
      e
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

Es gibt nun einen neuen Commit e, aber er wird nur von HEAD referenziert. Wir können natürlich noch einen weiteren Commit in diesem Zustand durchführen.

$ edit; git add; git commit

	 HEAD (refers to commit 'f')
	  |
	  v
      e---f
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

Tatsächlich können wir alle normalen Git-Operationen durchführen. Betrachten wir jedoch, was passiert, wenn wir dann master auschecken.

$ git checkout master

               HEAD (refers to branch 'master')
      e---f     |
     /          v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

Es ist wichtig zu erkennen, dass zu diesem Zeitpunkt nichts auf Commit f verweist. Schließlich wird Commit f (und damit auch Commit e) durch den routinemäßigen Git-Garbage-Collection-Prozess gelöscht, es sei denn, wir erstellen vorher eine Referenz. Wenn wir uns noch nicht von Commit f wegbewegt haben, kann jede der folgenden Aktionen eine Referenz darauf erstellen.

$ git checkout -b foo  # or "git switch -c foo"  (1)
$ git branch foo                                 (2)
$ git tag foo                                    (3)

erstellt einen neuen Zweig foo, der auf Commit f verweist, und aktualisiert dann HEAD, um auf den Zweig foo zu verweisen. Mit anderen Worten, wir befinden uns nach diesem Befehl nicht mehr im Detached HEAD-Zustand.
erstellt ähnlich einen neuen Zweig foo, der auf Commit f verweist, lässt aber HEAD gelöst.
erstellt ein neues Tag foo, das auf Commit f verweist, wobei HEAD gelöst bleibt.

Wenn wir uns von Commit f wegbewegt haben, müssen wir zuerst seinen Objekt-Namen wiederherstellen (typischerweise mit git reflog), und dann können wir eine Referenz darauf erstellen. Um beispielsweise die letzten beiden Commits anzuzeigen, auf die HEAD verwiesen hat, können wir einen der folgenden Befehle verwenden.

$ git reflog -2 HEAD # or
$ git log -g -2 HEAD

ARGUMENT DISAMBIGUATION

Wenn Sie git checkout <something> ausführen, versucht Git zu erraten, ob <something> als Zweig, Commit oder eine Reihe von Dateien gedacht ist, und wechselt dann entweder zu diesem Zweig oder Commit oder stellt die angegebenen Dateien wieder her.

Wenn es Unklarheiten gibt, behandelt Git <something> als Zweig oder Commit, aber Sie können den Doppelpunkt -- verwenden, um Git zu zwingen, den Parameter als Liste von Dateien und/oder Verzeichnissen zu behandeln, wie hier:

git checkout -- file.txt

BEISPIELE

1. Pfade

Die folgende Sequenz checkt den master-Zweig aus, setzt die Makefile auf zwei Revisionen zurück, löscht versehentlich hello.c und holt sie aus dem Index zurück.

$ git checkout master             (1)
$ git checkout master~2 Makefile  (2)
$ rm -f hello.c
$ git checkout hello.c            (3)

Zweig wechseln
eine Datei aus einem anderen Commit holen
hello.c aus dem Index wiederherstellen

Wenn Sie *alle* C-Quellcodedateien aus dem Index auschecken möchten, können Sie sagen:

$ git checkout -- '*.c'

Beachten Sie die Anführungszeichen um *.c. Die Datei hello.c wird ebenfalls ausgecheckt, obwohl sie nicht mehr im Arbeitsverzeichnis vorhanden ist, da die Dateinamensmuster abgeglichen werden, um Einträge im Index (nicht im Arbeitsverzeichnis der Shell) abzugleichen.

Wenn Sie einen unglücklichen Branch haben, der hello.c heißt, würde dieser Schritt als Anweisung zum Wechseln zu diesem Branch missverstanden werden. Sie sollten stattdessen Folgendes schreiben:

$ git checkout -- hello.c

2. Zusammenführen

Nachdem Sie im falschen Branch gearbeitet haben, würde der Wechsel zum korrekten Branch mit folgendem Befehl erfolgen:

$ git checkout mytopic

Ihr "falscher" Branch und der korrekte mytopic-Branch können sich jedoch in Dateien unterscheiden, die Sie lokal geändert haben. In diesem Fall würde der obige Checkout fehlschlagen, wie folgt:

$ git checkout mytopic
error: You have local changes to 'frotz'; not switching branches.

Sie können das Flag -m an den Befehl übergeben, was einen Drei-Wege-Merge versuchen würde.

$ git checkout -m mytopic
Auto-merging frotz

Nach diesem Drei-Wege-Merge werden die lokalen Änderungen *nicht* in Ihrer Indexdatei registriert. Daher würde git diff Ihnen die seit der Spitze des neuen Branches vorgenommenen Änderungen anzeigen.

3. Merge-Konflikt

Wenn während des Wechsels von Branches mit der Option -m ein Merge-Konflikt auftritt, sehen Sie Folgendes:

$ git checkout -m mytopic
Auto-merging frotz
ERROR: Merge conflict in frotz
fatal: merge program failed

An diesem Punkt zeigt git diff die Änderungen sauber zusammengeführt an, wie im vorherigen Beispiel, sowie die Änderungen in den konfliktbehafteten Dateien. Bearbeiten und lösen Sie den Konflikt und markieren Sie ihn wie gewohnt mit git add als gelöst.

$ edit frotz
$ git add frotz

KONFIGURATION

Alles unterhalb dieser Zeile in diesem Abschnitt wird selektiv aus der git-config[1]-Dokumentation übernommen. Der Inhalt ist derselbe wie dort zu finden.

checkout.defaultRemote

Wenn Sie git checkout <etwas> oder git switch <etwas> ausführen und nur ein Remote haben, kann dies implizit auf das Auschecken und Verfolgen von z.B. origin/<etwas> zurückfallen. Dies funktioniert nicht mehr, sobald Sie mehr als ein Remote mit einer <etwas>-Referenz haben. Diese Einstellung ermöglicht es, den Namen eines bevorzugten Remotes festzulegen, das bei der Eindeutigkeitsbestimmung immer Vorrang hat. Der typische Anwendungsfall ist, dies auf origin zu setzen.

Derzeit wird dies von git-switch[1] und git-checkout[1] verwendet, wenn git checkout <etwas> oder git switch <etwas> den <etwas>-Branch auf einem anderen Remote auscheckt, und von git-worktree[1], wenn git worktree add sich auf einen Remote-Branch bezieht. Diese Einstellung könnte in Zukunft für andere checkout-ähnliche Befehle oder Funktionalitäten verwendet werden.

checkout.guess

Stellt den Standardwert für die Option --guess oder --no-guess in git checkout und git switch bereit. Siehe git-switch[1] und git-checkout[1].

checkout.workers

Die Anzahl der parallelen Worker, die beim Aktualisieren des Arbeitsbaums verwendet werden. Standardmäßig ist dies eins, d.h. sequenzielle Ausführung. Wenn auf einen Wert kleiner als eins gesetzt, verwendet Git so viele Worker wie die Anzahl der verfügbaren logischen Kerne. Diese Einstellung und checkout.thresholdForParallelism wirken sich auf alle Befehle aus, die einen Checkout durchführen. Z.B. checkout, clone, reset, sparse-checkout usw.

Hinweis

Paralleler Checkout liefert normalerweise eine bessere Leistung für Repositories auf SSDs oder über NFS. Für Repositories auf rotierenden Festplatten und/oder Maschinen mit einer kleinen Anzahl von Kernen ist der sequentielle Standard-Checkout oft leistungsfähiger. Die Größe und der Komprimierungsgrad eines Repositorys können ebenfalls beeinflussen, wie gut die parallele Version funktioniert.

checkout.thresholdForParallelism

Beim parallelen Checkout mit einer kleinen Anzahl von Dateien können die Kosten für das Erzeugen von Subprozessen und die Interprozesskommunikation die Vorteile der Parallelisierung überwiegen. Diese Einstellung ermöglicht es Ihnen, die Mindestanzahl von Dateien festzulegen, für die ein paralleler Checkout versucht werden soll. Standardmäßig ist dies 100.

SIEHE AUCH

git-switch[1], git-restore[1]

Teil der git[1] Suite

Einrichtung und Konfiguration

Projekte holen und erstellen

Grundlegende Snapshots

Branching und Merging

Projekte teilen und aktualisieren

Inspektion und Vergleich

Patching

Debugging

E-Mail

Externe Systeme

Server-Administration

Anleitungen

Administration

Plumbing-Befehle