简体中文 ▾ 主题 ▾ 最新版本 ▾ git-switch 上次更新于 2.44.0

名称

git-switch - 切换分支

概要

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>

描述

切换到指定的分支。工作树和索引将更新以匹配该分支。所有新的提交将被添加到该分支的顶端。

可以选择使用 -c、-C 从具有相同名称的远程分支自动创建一个新分支（参见 --guess），或者使用 --detach 将工作树与任何分支分离，同时进行切换。

切换分支不需要干净的索引和工作树（即与 HEAD 相比没有差异）。但是，如果操作导致本地更改丢失，操作将被中止，除非使用 --discard-changes 或 --merge 另行告知。

此命令是实验性的。行为可能会改变。

选项

<分支>

要切换到的分支。

<新分支>

新分支的名称。

<起点>

新分支的起点。指定一个 <起点> 允许你基于历史中的其他点（而不是 HEAD 当前指向的位置）来创建一个分支。（或者，在 --detach 的情况下，允许你检查并从其他点分离。）

您可以使用 @{-N} 语法来引用使用 "git switch" 或 "git checkout" 操作切换到的第 N 个最后分支/提交。您也可以指定 -，它与 @{-1} 同义。这通常用于在两个分支之间快速切换，或者撤销错误的分支切换。

作为一种特殊情况，您可以将 A...B 用作 A 和 B 的合并基础的快捷方式，如果只有一个合并基础。您可以最多省略 A 和 B 中的一个，在这种情况下，它默认为 HEAD。

-c <新分支>
--create <新分支>

在切换到分支之前，创建一个名为 <新分支> 的新分支，从 <起点> 开始。这是事务性的等价物：

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

也就是说，除非 "git switch" 成功（例如，当该分支在另一个工作树中使用时），否则该分支不会被重置/创建（不仅当前分支保持不变，而且该分支也不会被重置为起点）。

-C <新分支>
--force-create <新分支>

类似于 --create，不同之处在于，如果 <新分支> 已经存在，它将被重置为 <起点>。这是一个方便的快捷方式：

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

切换到提交以进行检查和可丢弃的实验。有关详细信息，请参见 git-checkout[1] 中的“分离 HEAD”部分。

--guess
--no-guess

如果未找到 <分支>，但确实存在一个跟踪分支，且只有一个远程分支（称其为 <远程>）具有匹配的名称，则将其视为等效于：

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

如果该分支存在于多个远程仓库中，并且其中一个远程仓库的名称由 checkout.defaultRemote 配置变量指定，我们将使用该远程仓库进行消除歧义，即使 <分支> 在所有远程仓库中都不是唯一的。将其设置为例如 checkout.defaultRemote=origin，以便在 <分支> 模棱两可但在 origin 远程仓库上存在时，始终从该远程仓库检出远程分支。另请参见 git-config[1] 中的 checkout.defaultRemote。

--guess 是默认行为。使用 --no-guess 禁用它。

可以通过 checkout.guess 配置变量设置默认行为。

-f
--force

--discard-changes 的别名。

--discard-changes

即使索引或工作树与 HEAD 不同，也继续进行。索引和工作树都将被恢复以匹配切换目标。如果指定了 --recurse-submodules，子模块内容也将被恢复以匹配切换目标。这用于丢弃本地更改。

-m
--merge

如果您对一个或多个文件进行了本地修改，并且这些文件在当前分支和您要切换到的分支之间存在差异，则该命令将拒绝切换分支，以保留您的修改在上下文中。但是，使用此选项，将在当前分支、您的工作树内容和新分支之间进行三向合并，并且您将位于新分支上。

当发生合并冲突时，冲突路径的索引条目将保持未合并状态，您需要解决冲突并使用 git add 标记已解决的路径（如果合并应导致路径的删除，则使用 git rm）。

--conflict=<样式>

与上面的 --merge 选项相同，但更改了呈现冲突块的方式，覆盖了 merge.conflictStyle 配置变量。可能的值为 "merge"（默认）、"diff3" 和 "zdiff3"。

-q
--quiet

安静，禁止反馈消息。

--progress
--no-progress

默认情况下，如果进度状态连接到终端，则会在标准错误流上报告进度状态，除非指定了 --quiet。此标志即使未连接到终端也启用进度报告，而与 --quiet 无关。

-t
--track [direct|inherit]

创建新分支时，设置 "upstream" 配置。暗示 -c。有关详细信息，请参见 git-branch[1] 中的 --track。

如果未给出 -c 选项，则新分支的名称将从远程跟踪分支派生，方法是查看为相应远程仓库配置的 refspec 的本地部分，然后剥离初始部分直至 "*"。这将告诉我们，当从 origin/hack（或 remotes/origin/hack，甚至 refs/remotes/origin/hack）分叉时，使用 hack 作为本地分支。如果给定的名称没有斜杠，或者上述猜测导致空名称，则猜测将被中止。在这种情况下，您可以使用 -c 显式地给出一个名称。

--no-track

即使 branch.autoSetupMerge 配置变量为 true，也不设置 "upstream" 配置。

--orphan <新分支>

创建一个名为 <新分支> 的新的未出生分支。所有跟踪的文件都会被移除。

--ignore-other-worktrees

当想要的 ref 已经被另一个工作树检出时，git switch 会拒绝。此选项使它仍然检出该 ref。换句话说，该 ref 可以被多个工作树持有。

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

使用 --recurse-submodules 将根据超项目中记录的提交来更新所有活动子模块的内容。如果未使用任何内容（或 --no-recurse-submodules），则不会更新子模块工作树。就像 git-submodule[1] 一样，这将分离子模块的 HEAD。

示例

以下命令切换到 "master" 分支

$ git switch master

在错误的分支中工作后，切换到正确的分支将使用以下命令完成：

$ git switch mytopic

但是，您的“错误”分支和正确的“mytopic”分支可能在您本地修改的文件中存在差异，在这种情况下，上面的切换将失败，如下所示：

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

您可以为该命令提供 -m 标志，这将尝试进行三向合并

$ git switch -m mytopic
Auto-merging frotz

在此三向合并之后，本地修改未在您的索引文件中注册，因此 git diff 将向您显示自新分支顶端以来您所做的更改。

切换回我们切换到 mytopic 之前的上一个分支（即“master”分支）

$ git switch -

您可以从任何提交中创建一个新分支。例如，切换到“HEAD~3”并创建分支“fixup”

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

如果您想从同名的远程分支启动一个新分支

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

要检出提交 HEAD~3 以进行临时检查或实验，而无需创建新分支

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

如果结果证明您所做的任何事情都值得保留，您可以随时为其创建一个新名称（而无需切换离开）

$ git switch -c good-surprises

配置

本节中此行以下的所有内容都是从 git-config[1] 文档中选择性包含的。 内容与那里找到的内容相同

checkout.defaultRemote

当您运行 git checkout <something> 或 git switch <something> 并且只有一个远程仓库时，它可能会隐式地回退到检出并跟踪，例如 origin/<something>。一旦您有多个具有 <something> 引用的远程仓库，这将停止工作。此设置允许设置一个首选远程仓库的名称，该远程仓库在消除歧义时应始终优先。典型的用例是将此设置为 origin。

目前，git-switch[1] 和 git-checkout[1] 在 git checkout <something> 或 git switch <something> 将检出另一个远程仓库上的 <something> 分支时使用此设置，并且 git-worktree[1] 在 git worktree add 引用远程分支时也使用此设置。将来，此设置可能用于其他类似检出的命令或功能。

checkout.guess

为 git checkout 和 git switch 中的 --guess 或 --no-guess 选项提供默认值。 请参阅 git-switch[1] 和 git-checkout[1]。

checkout.workers

更新工作树时要使用的并行工作进程的数量。 默认值为 1，即顺序执行。 如果设置为小于 1 的值，Git 将使用与可用逻辑核心数量一样多的工作进程。 此设置和 checkout.thresholdForParallelism 会影响执行检出的所有命令。 例如，checkout，clone，reset，sparse-checkout 等。

注意：对于位于 SSD 上或通过 NFS 连接的存储库，并行检出通常可以提供更好的性能。 对于位于旋转磁盘上和/或具有少量核心的计算机上的存储库，默认的顺序检出通常表现更好。 存储库的大小和压缩级别也可能影响并行版本的性能。

checkout.thresholdForParallelism

当使用少量文件运行并行检出时，子进程生成和进程间通信的成本可能会超过并行化带来的收益。 此设置允许您定义应尝试并行检出的最小文件数。 默认值为 100。

另请参阅

git-checkout[1], git-branch[1]

GIT

属于 git[1] 套件的一部分

scroll-to-top