接到这个问题时，我的习惯是先确认自己所在仓库的 Git 版本。因为 git switch 是 Git 2.23 才加入的命令，版本不对，后面所有建议都要重新评估。

先确认Git版本

用 git --version 查看当前版本。然后把开发机、CI 脚本、Docker 镜像里的 Git 版本都确认一遍，不能只看本地。

使用`git checkout -b`还是`git switch -c`，首要判断依据是当前Git版本。`git switch`命令从Git 2.23版本开始提供，如果仓库所在的Git版本低于这个版本，就只能使用`git checkout -b`。可以通过在终端执行`git --version`查看版本号。对于长期维护的旧系统，可能无法升级Git，此时`checkout -b`是唯一选择。还要注意某些CI/CD环境可能预装了旧版Git，脚本中贸然使用`switch`会导致命令不存在。

很多人在本地用着新 Git，但忘了 .gitlab-ci.yml 或 Dockerfile 里装的是旧版，结果脚本一跑就报 command not found。所以第一步不是选命令，而是先摸清 Git 版本分布。

容易误判的地方

两条命令创建分支的结果是一样的，但 checkout 命令本身是过载的。它既能切分支，也能恢复文件，这个双重身份是误用的主要来源。

常见的一个坑是混淆`git checkout`和`git switch`的行为。`git checkout -b`可以创建分支，但`git checkout`不带`-b`时用于文件恢复，如果不小心把分支名写成文件名，会丢弃文件修改。`git switch`则不会，它强制要求操作对象是分支。另一个坑是某些Git版本中，`switch -c`与`checkout -b`在自动设置上游时存在细微差异，例如从远程分支创建本地分支时，`checkout -b`的默认跟踪行为可能因配置而异，需要显式使用`--track`确保一致。

所以在写脚本时，我通常不写 git checkout 来切分支，因为一旦变量为空或拼错，可能被当成路径处理。用 git switch 至少能避免这类误伤。

建议的处理顺序

在 Git 2.23 及以上版本，我的处理顺序是：交互式操作随便用哪个，但脚本和自动化优先用 switch -c。原因在于可读性和职责边界。

在Git 2.23及以上版本中，创建新分支时更推荐使用`git switch -c`，因为它的语义更聚焦。`switch`命令专门用于分支操作，而`checkout`还承担文件恢复等职责。编写脚本或自动化流程时，优先采用`git switch -c new-branch`，这样阅读代码的人无需考虑`checkout`在上下文中的其他含义，减少误解。如果习惯旧命令，继续使用`checkout -b`也完全没有问题，两者创建分支的结果一致。

如果你在维护一个持续集成脚本，应该把分支名放在变量里，并先做合法性校验。例如：

BRANCH_NAME="feature/login"
if git show-ref --verify --quiet "refs/heads/$BRANCH_NAME"; then
  echo "branch already exists"
else
  git switch -c "$BRANCH_NAME"
fi

这样即使分支已经存在，也不会把退出码搞错。

验证方法

创建之后要确认是否真的切过去了。执行 git status，第一行会显示当前分支。如果写脚本，用 git branch --show-current 可以拿到分支名；这个命令在 Git 2.22 之后才有，更老的版本可以用 git rev-parse --abbrev-ref HEAD 替代。

检查退出码也很有用。两条命令创建新分支成功时退出码都是 0，遇到分支已存在或者其他校验失败时返回非 0。在脚本中可以直接判断 $?，但更好的做法是用 git switch -c 出错时输出错误信息并中止。

如果创建后发现分支名写错了，可以用 git branch -m new-name 重命名当前分支，或者用 git switch -c correct-name 再从错误分支创建新分支。这个操作不依赖最初用的是哪条命令。

后续维护与风险边界

从远程分支创建本地分支时，两条命令的默认行为可能有细微差别。例如 git checkout -b local origin/remote 是否自动设置上游，取决于 branch.autoSetupMerge 配置。如果希望行为一致，显式加上 --track 最保险。

另一个要留意的是工作区未提交的修改。两条命令在切换分支时都会尝试将改动带过去，若目标分支在这些文件上有分叉，就会拒绝切换。这不是 switch 特有的限制，checkout -b 也一样。

长期来看，新项目建议统一使用 git switch 和 git restore，让命令语义更清晰。但如果是老仓库或者团队有大量旧习惯，保持 checkout -b 也完全可行，关键是形成规范并在文档里明确，避免混用造成理解成本。