本文分享了一系列现代Git命令，帮助开发者更高效地进行版本控制。文章介绍了`git switch`、`git restore`、`git sparse-checkout`、`git worktree`和`git bisect`等命令，这些命令分别在分支切换、文件恢复、部分目录检出、并行开发和快速定位Bug等方面提供了更便捷、更安全、更高效的解决方案。通过这些现代Git技巧，开发者可以告别过时的用法，提升开发效率，减少不必要的麻烦。

🚀 `git switch`：专为切换分支设计，取代了部分`git checkout`的功能。它提供了更清晰的语义和更安全的切换方式，例如`git switch other-branch`直接切换到其他分支，`git switch -`快速切回上一个分支，以及`git switch remote-branch`直接切换并跟踪远程分支。其优势在于避免了`checkout`的混淆，减少误操作。

🛠️ `git restore`：专注于恢复文件状态，分担了`git checkout`和`git reset`的部分职责。`git restore --staged some-file.py`取消暂存区的文件，等效于`git reset HEAD some-file.py`。`git restore --staged --worktree some-file.py`取消暂存并丢弃工作区修改（慎用），等效于`git checkout -- some-file.py`。`git restore --source HEAD~2 some-file.py`恢复到前两次提交的版本。其优势在于语义更清晰，职责分离，不易出错。

📦 `git sparse-checkout`：解决超大Monorepo的痛点，允许只检出所需的部分目录/文件。通过`git clone --no-checkout repo-url`跳过初始检出，然后使用`git sparse-checkout init --cone`初始化锥形模式，最后通过`git sparse-checkout set service/common`检出特定目录。其优势在于加快本地开发速度和CI/CD流水线效率。

🌳 `git worktree`：允许在同一个仓库的不同目录下并行处理多个分支。例如，在dev分支开发时，需要紧急修复master的线上Bug，可以使用`git worktree add -b hotfix ./hotfix master`创建一个基于master的hotfix分支工作副本。其优势在于完美解决多任务切换痛点，实现真正的并行开发。

🔍 `git bisect`：二分查找神器，用于精准定位引入Bug的提交。通过`git bisect start`、`git bisect bad HEAD`、`git bisect good v1.0`等命令标记坏提交和好提交，Git会自动切到中间提交进行测试，重复该过程直到定位到引入Bug的提交。其优势在于快速缩小范围，提高调试效率。

观帖子 https://fast.v2ex.com/t/1139495 有感

说实话，很多人（包括曾经的我）可能还停留在 Git 上古时期的用法上，就像它停留在 2005 年一样。但 git 这些年也在变化，在这里分享一些有用的 modern git 命令，帮你把 Git 用得更溜更省心，或许有些人还没用过。

git switch (2019 年, Git 2.23+)

干啥的？ 专治切换分支！取代了部分 git checkout 的功能。

香在哪？

git switch other-branch: 干净利落地切换分支。

git switch -: 瞬间切回上一个分支，跟 cd - 一样方便。

git switch remote-branch: 直接切换到远程分支并自动跟踪。

关键优势：

比万能的 git checkout 更专注、更安全！它会进行额外的检查，比如如果切换会导致本地未提交的改动丢失，它会中止操作，避免误操作悲剧。再也不用担心 checkout 的迷惑行为了。

git restore (2019 年, Git 2.23+)

干啥的？ 专门负责恢复文件状态！分担了 git checkout 和 git reset 的部分职责。

git restore --staged some-file.py: 把暂存区的文件撤回来（取消 add ），

等效 git reset HEAD some-file.py 。

git restore --staged --worktree some-file.py: 不仅取消暂存，还直接丢弃工作区的修改（⚠️慎重），

等效 git checkout -- some-file.py 。

git restore --source HEAD~2 some-file.py: 直接把文件恢复到前两次提交时的版本。

关键优势：

语义更清晰！命令名字 restore 就告诉你它在“恢复”东西。不再需要死记硬背 checkout 和 reset 在各种场景下的复杂参数组合，职责分离，不易出错。

git sparse-checkout (2020 年, Git 2.25+)

干啥的？

解救深陷超大 Monorepo 的开发者！只检出你需要的部分目录/文件。

克隆时跳过初始检出：git clone --no-checkout repo-url

初始化稀疏检出配置（锥形模式）：git sparse-checkout init --cone (初始只检出根目录)

检出特定目录：git sparse-checkout set service/common

git checkout main 后，神奇的事情发生了：只有你设置的部分目录/文件出现在工作区！

关键优势：

本地开发：git status, checkout 等命令快如闪电！尤其适合微服务架构的庞大仓库。

CI/CD： 大幅提升流水线效率！只拉取构建部署所需的部分代码，省时省资源。简直救命神器。

git worktree (2018 年)

干啥的？

让你在同一个仓库的不同目录下，同时并行处理多个分支！

假设你在 dev 分支开发，突然要紧急修复 master 的线上 Bug 。无需 stash 或提交半成品：

git worktree add -b hotfix ./hotfix master

瞬间在 ./hotfix 子目录得到一个干净的 hotfix 分支工作副本（基于 master ）。进去修改、测试、提交、推送一气呵成。搞定后，回到原目录继续 dev 分支的开发。

查看所有工作树：git worktree list

关键优势： 完美解决多任务切换痛点！告别分支来回切换的麻烦和干扰，实现真正的并行开发。

git bisect (虽不新，但强力安利！)

干啥的？ 二分查找神器！帮你精准定位引入 Bug 的那个提交。

香在哪？git bisect start: 开始二分查找。

git bisect bad HEAD: 标记当前提交（或已知的坏提交）是坏的。

git bisect good v1.0: 标记一个已知的好提交（比如上一个稳定版本标签）。

Git 会自动切到一个中间提交，你需要测试这个提交是好是坏：

坏的输入 git bisect bad

好的输入 git bisect good

重复步骤 4 ，Git 会自动缩小范围，直到定位到第一个引入 Bug 的提交。

git bisect reset: 结束查找，回到起点。

关键优势： 面对茫茫提交历史，手动排查 Bug 来源无异于大海捞针。bisect 用算法帮你快速缩小范围，精准打击罪魁祸首，调试效率暴增。强烈建议每个开发者都掌握。

最后一点感想：

很多时候，我们在 StackOverflow 搜 Git 问题，看到的最高赞答案可能已经是 10 年前的了。虽然它可能依然有效，但很可能已经不是最优、最方便、最现代的做法了（比如还在大量教你用 checkout 切分支、恢复文件）。