git switch引入后git checkout有哪些作用？是否已被废弃？

git switch 从2019年Git 2.23版本推出至今，本质上是针对git checkout功能过于重载的拆分优化，从来没有取代或废弃git checkout的官方计划。

功能拆分的对应关系 #

你之前日常使用的三类git checkout操作，现在已经有完全等价的git switch实现，功能100%对齐：

• 切换到已有分支：git switch <existing-branch> 等价于原有的 git checkout <existing-branch>
• 进入分离头指针状态：git switch --detach <hash> 等价于原有的 git checkout <hash>
• 新建分支并完成切换：git switch -c <new-branch-name> 等价于原有的 git checkout -b <new-branch-name>

这个拆分的核心初衷，是解决git checkout因为同时管「分支切换」和「文件覆盖」两类完全不同的操作，经常出现手滑输错参数——比如本来想切分支，结果把路径写成了文件名，直接把工作区未提交的修改给硬覆盖了，连回退的机会都没有——的高频踩坑问题。把两类操作拆分给两个语义单一的命令，从入口层面就降低误操作概率。

git checkout 现在留存的核心作用 #

在分支切换、文件恢复的功能分别被git switch、git restore占据推荐位之后，git checkout至今还保留三个不可替代的价值：

• 全链路历史兼容。所有写在CI流程、团队自动化脚本、老旧协作文档里的git checkout命令，在最新版Git上可以无修改直接运行，不会出现命令不存在、参数失效的问题，这对依赖老工具链的团队至关重要。
• 完整保留文件覆盖类的操作能力。比如大家用了十几年的 git checkout -- <file> 把工作区文件恢复到暂存区版本的操作，至今完全可用，没有任何功能限制，只是官方更推荐语义更清晰的git restore <file>写法而已。
• 特殊场景的参数兼容。比如跨标签、跨远程引用的批量校验、历史版本回退的自定义参数场景，git checkout经过十几年的迭代打磨，参数兼容性比新推出的git switch覆盖场景更广，没有因为功能拆分被阉割过任何历史能力。

关于“是否废弃”的明确判定 #

Git官方从来没有将git checkout标记为废弃状态。

Git项目对内置命令的兼容原则非常严格：已经公开稳定运行超过10年的核心命令，除非存在严重的安全漏洞，否则永远不会被下线。现在文档里逐步引导大家用git switch、git restore，只是出于降低误操作的体验优化，不是强制要求替换老命令。你现在哪怕继续所有版本管理操作全用git checkout完成，也不会遇到任何功能缺失的问题。

内容的提问来源于stack exchange，提问作者HelloWorld