-q –quiet
Quiet, Feedback-Nachrichten unterdrücken.
–progress –no-progress
Der Fortschrittsstatus wird standardmäßig im Standardfehlerstream gemeldet, wenn er an ein Terminal angehängt ist, es sei denn, --quietist angegeben. Dieses Flag ermöglicht die Fortschrittsberichterstattung, auch wenn es nicht an ein Terminal angehängt ist, unabhängig von --quiet.
-f –force
Fahren Sie beim Wechseln von Zweigen fort, auch wenn der Index oder der Stammbaum von HEAD . Dies wird verwendet, um wegzuwerfenlokale Änderungen.
Wenn Sie Pfade aus dem Index auschecken, schlagen Sie bei nicht zusammengeführten Einträgen nicht fehl; stattdessen werden nicht zusammengeführte Einträge ignoriert.
–ours –theirs
Wenn Sie Pfade aus dem Index auschecken, überprüfen Sie stage #2(ours) oder # 3 (theirs) für nicht zusammengeführte Pfade.
Beachten Sie, dass während git rebase und git pull --rebase unsere und ihre vertauscht erscheinen können; --ours gibt die Version von der Branche an, auf die die Änderungen basieren, während --theirs die Version von der das hält Ihre Arbeit, die neu ausgerichtet wird.
Dies liegt daran, dass rebase in einem Workflow verwendet wird, der die Historie auf der Fernbedienung als die gemeinsam genutzte kanonische behandelt und die Arbeit auf dem Zweig, den Sie neu erstellen, als die zu integrierende Arbeit eines Drittanbieters behandelt, und Sie vorübergehend die Rolle des Verwalters der kanonischen Historie während der Neugestaltung übernehmen. Als Hüter der kanonischen Geschichte müssen Sie die Geschichte von der Fernbedienung aus als ours (dh „unsere gemeinsame kanonische Geschichte“) anzeigen, während Sie auf Ihrem Seitenzweig als theirs (dh. „die Arbeit eines Mitwirkenden darüber“).
-b <new_branch>
Erstelle einen neuen Zweig mit dem Namen <new_branch> und starte ihn bei<start_point>; siehe git-branch für Details.
-B <new_branch> -t –track
Richten Sie beim Erstellen eines neuen Zweigs die Konfiguration „upstream“ ein. Siehe „–track“ in git-branch für Details.
Wenn keine -b Option angegeben ist, wird der Name des neuen Zweigs aus dem Remote-Tracking-Zweig abgeleitet, indem Sie sich den lokalen Teil der für die entsprechende Fernbedienung konfigurierten refspec ansehen und dann den Anfangsteil bis zum „*“ entfernen.Dies würde uns sagen, dass wir hack als lokalen Zweig verwenden sollen, wenn wir von origin/hack (oder remotes/origin/hack oder sogarrefs/remotes/origin/hack) abzweigen. Wenn der angegebene Name keinen Schrägstrich hat oder das Obige zu einem leeren Namen führt, wird das Raten abgebrochen. In einem solchen Fall können Sie explizit einen Namen mit -b angeben.
–no-track
Richten Sie keine „Upstream“ -Konfiguration ein, auch wenn diebranch.autoSetupMerge -Konfigurationsvariable true ist.
–guess –no-guess
Wenn <branch> nicht gefunden wird, aber es gibt einen Trackingbranch in genau einer Fernbedienung (nenne es <remote>) mit Amatching-Namen, behandeln Sie als äquivalent zu
$ git checkout -b <branch> --track <remote>/<branch>
Wenn der Zweig in mehreren Fernbedienungen vorhanden ist und eine von ihnen nach der checkout.defaultRemote Konfigurationsvariablen benannt ist, verwenden wir diese zur Begriffsklärung, auch wenn die <branch> nicht für alle Fernbedienungen einzigartig ist. Stellen Sie es auf.g. checkout.defaultRemote=origin remotebranches immer von dort auschecken, wenn <branch> nicht eindeutig ist, aber auf theorigin remote vorhanden ist. Siehe auch checkout.defaultRemote ingit-config.
--guess ist das Standardverhalten. Verwenden Sie --no-guess , um es zu deaktivieren.
Das Standardverhalten kann über die checkout.guess Konfigurationsvariable eingestellt werden.
-l
Erstelle das Reflog des neuen Zweigs; siehe git-branch fürdetails.
-d –detach
Anstatt einen Zweig auszuchecken, um daran zu arbeiten, überprüfen Sie acommit auf Inspektion und wegwerfbare Experimente.Dies ist das Standardverhalten von git checkout <commit>, wenn<commit> kein Zweigname ist. Siehe den Abschnitt „FREISTEHENDER KOPF“ unten für Details.
–orphan <new_branch>
Erstellen Sie einen neuen Orphan-Zweig mit dem Namen <new_branch>, gestartet von<start_point> und wechseln Sie zu ihm. Der erste Commit, der in diesem neuen Zweig ausgeführt wird, hat keine Eltern und ist der Stamm einer neuen Geschichte, die vollständig von allen anderen Zweigen und Commits getrennt ist.
Der Index und der Arbeitsbaum werden so angepasst, als hätten Sie zuvorgit checkout <start_point> ausgeführt. Auf diese Weise können Sie einen neuen Verlauf startendas zeichnet eine Reihe von Pfaden auf, die <start_point> ähneln, indem Sie einfachgit commit -a ausführen, um das Root-Commit durchzuführen.
Dies kann nützlich sein, wenn Sie den Baum aus einem Commit veröffentlichen möchten, ohne den vollständigen Verlauf anzuzeigen. Vielleicht möchten Sie dies tun, um einen Open-Source-Zweig eines Projekts zu veröffentlichen, dessen aktueller Baum „sauber“ ist, dessen vollständiger Verlauf jedoch proprietäre oder anderweitig belastete Code-Bits enthält.
Wenn Sie einen getrennten Verlauf starten möchten, der eine Reihe von Pfaden aufzeichnet, die sich völlig von der von <start_point> unterscheiden, sollten Sie den Index und den Arbeitsbaum direkt nach dem Erstellen des orphanbranch löschen, indem Sie git rm -rf . von der obersten Ebene des Arbeitsbaums aus ausführen.Danach sind Sie bereit, Ihre neuen Dateien vorzubereiten, den Dateibaum neu zu füllen, sie von einem anderen Ort zu kopieren, einen Tarball zu extrahieren usw.
–ignore-skip-worktree-bits
Im sparse Checkout-Modus würden git checkout -- <paths> nur Einträge aktualisieren, die mit <paths> und sparse patternsin $GIT_DIR/info/sparse-checkout übereinstimmen. Diese Option ignoriert die Sparse-Muster und fügt alle Dateien in <paths> hinzu.
-m –merge
Wenn Sie beim Wechseln von Zweigen 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, Zweige zu wechseln, um Ihre Änderungen im Kontext beizubehalten.Mit dieser Option wird jedoch eine Drei-Wege-Zusammenführung zwischen dem aktuellen Zweig, dem Inhalt Ihres Arbeitsbaums und dem neuen Zweig durchgeführt, und Sie befinden sich im neuen Zweig.
Wenn ein Zusammenführungskonflikt auftritt, werden die Indexeinträge für Konfliktpfade nicht zusammengeführt, und Sie müssen die Konflikte lösen und die aufgelösten Pfade mit git add markieren (oder git rm wenn die Zusammenführung zum Löschen des Pfads führen sollte).
Beim Auschecken von Pfaden aus dem Index können Sie mit dieser Option die in Konflikt stehende Zusammenführung in den angegebenen Pfaden neu erstellen.
Beim Wechseln von Zweigen mit --merge können alle Änderungen verloren gehen.
–conflict=<style>
Das gleiche wie --merge Option oben, aber ändert die Art und Weise theconflicting hunks präsentiert werden, überschreibt diemerge.conflictStyle Konfigurationsvariable. Mögliche Werte sind“merge“ (Standard) und „diff3″ (zusätzlich zu dem, was durch“merge“ Stil gezeigt wird, zeigt den ursprünglichen Inhalt).
-p –patch
Wählen Sie interaktiv Hunks in der Differenz zwischen dem<tree-ish> (oder dem Index, falls nicht angegeben) und dem workingtree . Die ausgewählten Hunks werden dann umgekehrt auf den Indexbaum angewendet (und wenn ein <tree-ish> angegeben wurde, der Index).
Dies bedeutet, dass Sie git checkout -p verwenden können, um selektiv Verwerfungen aus Ihrem aktuellen Arbeitsbaum zu entfernen. Im Abschnitt „Interaktiver Modus“ von git-add erfahren Sie, wie Sie den --patch -Modus bedienen.
Beachten Sie, dass diese Option standardmäßig den Modus „Kein Overlay“ verwendet (siehe auch--overlay) und derzeit keinen Overlay-Modus unterstützt.
–ignore-other-worktrees
git checkout lehnt ab, wenn die gewünschte Referenz bereits von einem anderen worktree ausgecheckt wurde. Mit dieser Option wird das Refout trotzdem überprüft. Mit anderen Worten, die Referenz kann von mehr als einem gehalten werdenworktree.
–overwrite-ignore –no-overwrite-ignore
Überschreibt ignorierte Dateien beim Wechseln von Zweigen. 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
Mit --recurse-submodules wird der Inhalt aller activesubmodules entsprechend dem im Superprojekt aufgezeichneten Commit aktualisiert. 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 git-submodule löst dies HEAD von thesubmodule .
–overlay –no-overlay
Im Standard-Overlay-Modus git checkout neverremoves Dateien aus dem Index oder dem Arbeitsbaum. Wenn Sie --no-overlay angeben, werden Dateien, die im Index und im Dateibaum, aber nicht in <tree-ish> angezeigt werden, entfernt, damit sie genau mit <tree-ish> übereinstimmen.
–pathspec-from-file=<file>
Pathspec wird in <file> anstelle von Befehlszeilenargumenten übergeben. Wenn<file> genau - ist, wird die Standardeingabe verwendet. Pathspecelements werden durch LF oder CR/LF getrennt. Pathspec-Elemente können wie für die Konfigurationsvariable core.quotePath(siehe git-config) angegeben werden. Siehe auch --pathspec-file-nul undglobal --literal-pathspecs.
–pathspec-file-nul
Nur sinnvoll mit --pathspec-from-file. Pathspec-Elemente werden mit NUL-Zeichen getrennt und alle anderen Zeichen werden wörtlich genommen (einschließlich Zeilenumbrüche und Anführungszeichen).
<branch>
Branch to checkout; Wenn es sich um einen Zweig handelt (dh einen Namen, dem „refs/heads/“ vorangestellt ist), ist thatbranch ausgecheckt. Andernfalls, wenn es sich auf ein validcommit bezieht, wird Ihre HEAD „losgelöst“ und Sie befinden sich nicht mehr in einem Zweig (Details siehe unten).
Als Sonderfall können Sie A...B als Abkürzung für die merge base von A und B wenn es genau eine Merge base gibt. Sie können höchstens eine von A und B , in diesem Fall ist es standardmäßig HEAD .
<new_branch>
Name für den neuen Zweig.
<start_point>
Der Name eines Commits, bei dem der neue Branch gestartet werden soll; siehe gitzweig für Details. Der Standardwert ist HEAD.
Als Sonderfall können Sie "A...B" als Abkürzung für die merge base von A und B wenn es genau eine Merge base gibt. Sie können höchstens eine von A und B , in diesem Fall ist es standardmäßig HEAD .
<tree-ish>
Baum zum Auschecken (wenn Pfade angegeben sind). Falls nicht angegeben, wird der Index verwendet.
Als Sonderfall können Sie "A...B" als Abkürzung für die merge base von A und B wenn es genau eine Merge base gibt. Sie können höchstens eine von A und B , in diesem Fall ist es standardmäßig HEAD .
—
Interpretiert keine weiteren Argumente als Optionen.
<pathspec>…
Begrenzt die von der Operation betroffenen Pfade.
Weitere Informationen finden Sie im Eintrag pathspec in gitglossary.