如何使用 git worktree 同时处理多个分支任务

你是否遇到过这样的场景：正在 feature/login 分支上开发新功能，突然收到紧急反馈，需要立刻切换到 hotfix/critical-bug 分支修复线上问题。你不得不 stash 当前未完成的修改，切换分支，修复问题，提交，再切回来，恢复 stash，然后重新进入状态。如果此时又来了一个代码审查请求，需要你切到 review/pr-123 分支跑测试，整个过程就会变得异常繁琐，而且极易出错。

这种频繁切换分支带来的上下文丢失和操作开销，是很多开发者日常的痛点。有没有一种方式，能让你同时拥有多个工作目录，每个目录对应一个分支，彼此互不干扰？答案就是 git worktree。

什么是 git worktree

git worktree 是 Git 从 2.5 版本开始引入的一个命令，它允许你从同一个 Git 仓库中检出多个工作树（working tree）。每个工作树都关联到不同的分支，并且拥有自己独立的工作目录和暂存区。你可以把它理解为“同一个 .git 仓库，多个并列的工作文件夹”。

与传统的 git clone 不同，worktree 共享同一个对象数据库和引用，因此不会重复占用磁盘空间，也不会产生多个远程仓库的同步问题。所有工作树中的提交、分支、标签都是实时共享的。

基本用法

创建新的工作树

假设你当前在项目主目录中，位于 main 分支。现在需要为 feature/payment 分支创建一个独立的工作树：

git worktree add ../project-payment feature/payment

这条命令会在 ../project-payment 目录下创建一个新的工作树，并自动检出 feature/payment 分支。如果该分支不存在，Git 会基于当前 HEAD 创建一个新分支。

你也可以直接基于某个提交或标签创建：

git worktree add ../project-hotfix v1.2.3

这会创建一个处于“分离 HEAD”状态的工作树，适合临时查看旧版本代码。

查看现有工作树

git worktree list

输出类似：

/path/to/project          abc1234 [main]
/path/to/project-payment  def5678 [feature/payment]
/path/to/project-hotfix   9876543 (detached HEAD)

删除工作树

当你完成某个分支的任务后，可以直接删除对应的工作树目录，然后执行：

git worktree remove ../project-payment

如果工作树中有未提交的修改，remove 会拒绝删除。你可以先提交或 stash，也可以使用 --force 强制删除。

移动和修复工作树

如果手动移动了工作树目录，可以用 git worktree move 来更新 Git 的记录：

git worktree move ../project-payment ../new-location/payment

如果工作树因为某些原因损坏或路径失效，可以运行：

git worktree repair

实际工作流示例

假设你正在开发一个大型项目，同时需要处理三件事：

1. 在 main 分支上维护稳定版本
2. 开发 feature/search 新功能
3. 修复 bugfix/header-layout 紧急问题

你可以这样组织：

# 主目录保持在 main
cd ~/projects/myapp

# 创建功能开发工作树
git worktree add ../myapp-search feature/search

# 创建紧急修复工作树
git worktree add ../myapp-header bugfix/header-layout

现在你的目录结构可能是：

~/projects/
├── myapp/            # main 分支
├── myapp-search/     # feature/search 分支
└── myapp-header/     # bugfix/header-layout 分支

每个目录都可以独立打开编辑器、运行测试、执行构建。在 myapp-search 中提交的代码会立即反映到主仓库的对象库中，其他工作树也能看到这个提交（通过 git log 等命令），但各自的工作目录互不影响。

当紧急修复完成后，你可以在 myapp-header 中提交并推送，然后删除该工作树：

cd ../myapp-header
git add . && git commit -m "fix: header layout on mobile"
git push origin bugfix/header-layout
cd ../myapp
git worktree remove ../myapp-header

整个过程无需 stash，无需切换分支，主目录中的开发环境始终保持原样。

注意事项与最佳实践

不要在不同工作树中检出同一个分支。 Git 会明确拒绝这种操作，因为同一个分支只能被一个工作树检出。这避免了两个工作目录同时修改同一分支带来的混乱。

子模块和钩子。 每个工作树都有独立的 .git 文件（实际上是一个指向主仓库的文本文件），但共享钩子（hooks）和配置。如果你使用了 pre-commit 等钩子，它们会在所有工作树中生效。

IDE 支持。 大多数现代 IDE（如 VS Code、IntelliJ IDEA）都能正常识别 worktree 目录，你可以像打开普通项目一样打开它们。不过要注意，某些 IDE 的 Git 集成可能对 worktree 的支持不够完善，必要时可以改用命令行操作。

清理习惯。 任务完成后及时 git worktree remove，避免磁盘上积累大量废弃的工作树。定期运行 git worktree prune 可以清理那些已被手动删除目录的残留记录。

总结

git worktree 是一个被低估但极其强大的 Git 功能。它让你能够以极低的成本并行处理多个分支任务，彻底告别频繁 stash 和切换分支的烦恼。无论是紧急修复、代码审查，还是同时开发多个功能，worktree 都能让你的工作流更加流畅和高效。如果你还没有尝试过，不妨从下一个任务开始，用 git worktree add 开启多线程工作模式。

未经允许不得转载：任鹏个人博客 » 如何使用 git worktree 同时处理多个分支任务