English ▾ Themen ▾ Neueste Version ▾ git-switch zuletzt aktualisiert in 2.51.0

NAME

git-switch - Zweige wechseln

SYNOPSIS

git switch [<options>] [--no-guess] <branch>
git switch [<options>] --detach [<start-point>]
git switch [<options>] (-c|-C) <new-branch> [<start-point>]
git switch [<options>] --orphan <new-branch>

BESCHREIBUNG

Wechselt zu einem angegebenen Zweig. Der Arbeitsbaum und der Index werden aktualisiert, um dem Zweig zu entsprechen. Alle neuen Commits werden an die Spitze dieses Zweigs angehängt.

Optional kann ein neuer Zweig mit entweder -c, -C, automatisch von einem Remote-Zweig mit gleichem Namen (siehe --guess) erstellt oder der Arbeitsbaum mit --detach von jedem Zweig gelöst werden, zusammen mit dem Wechseln.

Das Wechseln von Zweigen erfordert keinen sauberen Index und Arbeitsbaum (d.h. keine Unterschiede im Vergleich zu HEAD). Die Operation wird jedoch abgebrochen, wenn sie zum Verlust lokaler Änderungen führt, es sei denn, es wird anders mit --discard-changes oder --merge angegeben.

OPTIONEN

<branch>

Zu welchem Zweig gewechselt werden soll.

<new-branch>

Name für den neuen Zweig.

<start-point>

Der Startpunkt für den neuen Zweig. Die Angabe eines <start-point> ermöglicht es Ihnen, einen Zweig basierend auf einem anderen Punkt in der Historie zu erstellen als dort, wo HEAD gerade hinzeigt. (Oder im Fall von --detach, ermöglicht es Ihnen, einen anderen Punkt zu inspizieren und von ihm zu lösen.)

Sie können die Syntax @{-<N>} verwenden, um auf den <N>-ten zuletzt gewechselten Zweig/Commit zu verweisen, der mit einer git switch oder git checkout Operation verwendet wurde. Sie können auch - angeben, was synonym zu @{-1} ist. Dies wird oft verwendet, um schnell zwischen zwei Zweigen zu wechseln oder einen versehentlichen Zweigwechsel rückgängig zu machen.

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

-c <new-branch>
--create <new-branch>

Erstellt einen neuen Zweig namens <new-branch>, der bei <start-point> beginnt, bevor zu dem Zweig gewechselt wird. Dies ist das transaktionale Äquivalent zu

$ git branch <new-branch>
$ git switch <new-branch>

das heißt, der Zweig wird nicht zurückgesetzt/erstellt, es sei denn, git switch ist erfolgreich (z.B. wenn der Zweig in einem anderen Worktree verwendet wird, nicht nur der aktuelle Zweig bleibt gleich, sondern der Zweig wird auch nicht auf den Startpunkt zurückgesetzt).

-C <new-branch>
--force-create <new-branch>

Ähnlich wie --create, außer dass, wenn <new-branch> bereits existiert, er auf <start-point> zurückgesetzt wird. Dies ist eine praktische Abkürzung für

$ git branch -f _<new-branch>_
$ git switch _<new-branch>_
-d
--detach

Zu einem Commit wechseln zur Inspektion und für verwerfbare Experimente. Siehe den Abschnitt "DETACHED HEAD" in git-checkout[1] für Details.

--guess
--no-guess

Wenn <branch> nicht gefunden wird, aber es einen Tracking-Zweig in genau einem Remote (nennen wir ihn <remote>) mit einem übereinstimmenden Namen gibt, wird dies als äquivalent zu behandelt

$ git switch -c <branch> --track <remote>/<branch>

Wenn der Zweig in mehreren Remotes existiert und eines davon durch die Konfigurationsvariable checkout.defaultRemote benannt ist, wird dieses zur Unterscheidung verwendet, auch wenn <branch> über alle Remotes hinweg nicht eindeutig ist. Setzen Sie es z.B. auf checkout.defaultRemote=origin, um Remote-Zweige immer von dort auszuchecken, wenn <branch> mehrdeutig ist, aber auf dem origin Remote existiert. 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.

-f
--force

Ein Alias für --discard-changes.

--discard-changes

Fährt fort, auch wenn der Index oder der Arbeitsbaum von HEAD abweichen. Sowohl der Index als auch der Arbeitsbaum werden wiederhergestellt, um dem Wechselziel zu entsprechen. Wenn --recurse-submodules angegeben ist, wird auch der Inhalt von Submodulen wiederhergestellt, um dem Wechselziel zu entsprechen. Dies wird verwendet, um lokale Änderungen zu verwerfen.

-m
--merge

Wenn Sie lokale Änderungen an einer oder mehreren Dateien haben, die sich zwischen dem aktuellen Zweig und dem zu wechselnden Zweig 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, den Inhalten Ihres Arbeitsbaums und dem neuen Zweig durchgeführt, und Sie befinden sich auf dem neuen Zweig.

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

--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.

-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.

-t
--track[ (direct|inherit)]

Beim Erstellen eines neuen Zweigs wird die "upstream"-Konfiguration eingerichtet. -c ist impliziert. Siehe --track in git-branch[1] für Details.

Wenn keine Option -c angegeben wird, wird der Name des neuen Zweigs vom Remote-Tracking-Zweig abgeleitet, indem der lokale Teil des Refspecs, der für das entsprechende Remote konfiguriert ist, betrachtet und dann der Teil 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) abzweigen. 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 -c angeben.

--no-track

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

--orphan <new-branch>

Erstellt einen neuen, ungeborenen Zweig namens <new-branch>. Alle getrackten Dateien werden entfernt.

--ignore-other-worktrees

git switch lehnt ab, wenn der gewünschte Ref bereits von einem anderen Worktree ausgecheckt ist. Diese Option bewirkt, dass der Ref trotzdem ausgecheckt wird. Mit anderen Worten, der Ref kann von mehr als einem Worktree gehalten werden.

--recurse-submodules
--no-recurse-submodules

Die Verwendung von --recurse-submodules aktualisiert den Inhalt aller aktiven Submodule gemäß dem im Superprojekt aufgezeichneten Commit. Wenn nichts (oder --no-recurse-submodules) verwendet wird, werden die Arbeitsbäume der Submodule nicht aktualisiert. Genau wie git-submodule[1] löst dies HEAD der Submodule.

BEISPIELE

Der folgende Befehl wechselt zum Zweig "master"

$ git switch master

Nachdem Sie im falschen Zweig gearbeitet haben, würde der Wechsel zum richtigen Zweig wie folgt erfolgen:

$ git switch mytopic

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

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

Sie können dem Befehl die Option -m übergeben, die einen Drei-Wege-Merge versuchen würde:

$ git switch -m mytopic
Auto-merging frotz

Nach diesem Drei-Wege-Merge sind die lokalen Änderungen nicht in Ihrer Indexdatei registriert, sodass git diff Ihnen anzeigen würde, welche Änderungen Sie seit der Spitze des neuen Zweigs vorgenommen haben.

Um zum vorherigen Zweig zurückzukehren, bevor wir zu mytopic gewechselt sind (d.h. zum "master"-Zweig)

$ git switch -

Sie können einen neuen Zweig von jedem Commit erstellen. Beispiel: Wechseln Sie zu "HEAD~3" und erstellen Sie den Zweig "fixup"

$ git switch -c fixup HEAD~3
Switched to a new branch 'fixup'

Wenn Sie einen neuen Zweig von einem Remote-Zweig mit demselben Namen starten möchten

$ git switch new-topic
Branch `new-topic` set up to track remote branch `new-topic` from `origin`
Switched to a new branch `new-topic`

Um den Commit HEAD~3 zur temporären Inspektion oder zu Experimenten auszuchecken, ohne einen neuen Zweig zu erstellen

$ git switch --detach HEAD~3
HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'

Wenn sich herausstellt, dass das, was Sie getan haben, beibehalten werden soll, können Sie ihm jederzeit einen neuen Namen geben (ohne zu wechseln)

$ git switch -c good-surprises

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-checkout[1], git-branch[1]

GIT

Teil der git[1] Suite