1. 引言：那个让你抓狂的“突发需求”

想象一下这个场景： 你正在 feature-awesome 分支上热火朝天地写着几百行核心代码，正处于“心流”状态。突然，老板冲进办公室：“生产环境出 Bug 了，赶紧切到 master 修复一下！”

此时的你陷入了纠结：

• 方案 A：git stash。把改了一半的代码藏起来。等你修完 Bug 回来 stash pop 时，往往会因为忘记了当时的环境或者遇到冲突而一脸懵逼。

• 方案 B：直接 git checkout。报错！Git 提醒你本地修改会被覆盖，切不过去。

• 方案 C：暴力 git clone。在另一个文件夹再克隆一份项目。不仅浪费硬盘空间，还得重新装依赖、配置环境变量，半小时过去了。

有没有一种办法，能让我像切浏览器标签页一样，同时打开多个分支工作，互不干扰？

这就是我们要聊的主角：Git Worktree。

2. 概念拆解：什么是 Worktree？

生活化类比：乐高工作台

想象你正在拼一套复杂的“星球大战”乐高（这是你的主项目）。

• 传统的 Git 像是一个只有一个桌面的工作台。你想拼“死星”，就得把还没拼好的“千年隼”拆掉或收进盒子里，腾出地方。

• Git Worktree 则是给你瞬间变出第二个、第三个独立的工作台。这些工作台共享同一个零件仓库（.git 目录），但桌面是独立的。你可以在台子 A 修 Bug，在台子 B 写新功能，抬头就能看见彼此，转身就能切换。

核心逻辑

在 Git 的世界里，一个仓库通常由两部分组成：

1. .git 文件夹（仓库的灵魂：存储历史、版本信息）。

2. 工作区（仓库的肉体：你实际看到的代码文件）。

默认情况下，一个灵魂只配一个肉体。但 Git Worktree 允许一个 .git 文件夹同时管理多个工作区。

3. 动手实战：三秒开启新工作区

假设你现在在 main 分支，需要去 hotfix 分支修 Bug。

第一步：创建新工作区

不要切换分支，直接运行：

# 格式：git worktree add <路径> <分支名>
git worktree add ../my-project-hotfix hotfix

这条命令的意思是：在当前目录的上一级创建一个名为 my-project-hotfix 的文件夹，并在这个文件夹里检出 hotfix 分支。

第二步：进入并开始工作

cd ../my-project-hotfix
# 这里的代码完全独立，随便改，随便编译！

第三步：修完撤退

Bug 修复并提交后，你可以回到主目录，把临时工作区删掉：

# 回到主仓库
cd ../my-project
# 移除工作区记录
git worktree remove ../my-project-hotfix

4. 进阶深潜：新手避坑指南

常见陷阱：同一个分支不能同时检出

Git 有一个保护机制：同一个分支不能在两个不同的工作区中同时被检出。 如果你尝试在 Worktree A 中切换到 Worktree B 正在使用的分支，Git 会无情地拒绝你。这是为了防止多个工作区同时修改同一个引用导致的数据错乱。

最佳实践：统一管理 Worktree

如果你频繁使用这个功能，建议将所有的 Worktree 放在项目根目录之外的一个统一文件夹里，或者在项目内创建一个 .worktrees/ 目录并将其加入 .gitignore。

常用命令清单： | 命令 | 用途 | | :--- | :--- | | git worktree list | 查看当前所有的工作区及其所在路径 | | git worktree add -b <new-branch> <path> | 创建一个新分支并同时开启新工作区 | | git worktree prune | 清理那些已经手动删除文件夹但还没注销的工作区信息 |

5. 总结与延伸

Git Worktree 的核心价值在于：它打破了“分支切换”带来的上下文丢失，实现了物理隔离的并行开发。

它比 stash 更安全，比 clone 更轻量（共享 .git 目录，极省空间）。