作为开发人员，你是否遇到过这样的场景：正在 feature 分支写新功能，突然需要紧急修复 main 分支的 bug，切换分支前得先stash暂存代码，修复完回来又要stash pop，万一暂存多了还容易搞混；或者为了避免切换麻烦，直接克隆两个相同仓库，结果多占了一倍磁盘空间……

如果你也被这些问题困扰，那今天要介绍的 Git Worktree 绝对是你的救星 —— 它能让同一个 Git 仓库的不同分支，分别存在于独立的文件夹中，既不用频繁暂存，又能节省磁盘空间，真正实现 “多分支并行开发”。

一、先搞懂：Git Worktree 是什么？

Git Worktree 的核心逻辑很简单：让一个 Git 仓库（共享同一个.git目录）对应多个独立的工作目录，每个工作目录可以检出不同的分支。

打个比方：你有一个 “代码历史库”（即仓库的.git文件夹，存储所有分支、提交记录），然后给这个 “历史库” 配了多个 “工作房间”（不同的文件夹），每个 “房间” 里放着某一个分支的代码。你可以在 A 房间改 feature 分支，同时在 B 房间改 main 分支，两者互不干扰 —— 因为它们共享底层的 “历史库”，提交记录会实时同步。

对比传统方案，它的优势一目了然：

  • 省空间：多工作目录共享.git，只多存一份分支代码（而非完整历史），比克隆多个仓库节省 50%+ 空间

  • 高效率：不用频繁stash/checkout，切换分支只需切换文件夹

  • 环境干净：每个分支的依赖（如node_modules）、配置文件互不影响

二、上手实操：Git Worktree 核心命令

以 “在 main 分支仓库基础上，创建 feature-A 分支工作树” 为例，带你走完全流程：

1. 查看当前工作树（可选）

先确认当前仓库已有的工作树，避免重复创建：

# 1. 进入原仓库目录（示例：main分支所在的glog\_new）

cd /Users/macm4/code/glog/glog\_new

# 2. 查看所有工作树（格式：工作目录路径 分支名 \[提交哈希]）

git worktree list

首次使用时，仅显示原仓库路径（如/Users/macm4/code/glog/glog_new 3cd64df [main]）。

2. 创建新工作树（关键步骤）

命令格式：git worktree add <新工作目录路径> <目标分支名>

示例：在glog_new同级目录，创建glog_featureA文件夹存放 feature-A 分支代码：

# 执行创建命令（../表示当前目录的上一级）

git worktree add ../glog\_featureA feature-A

执行成功后，Git 会自动检出 feature-A 分支代码到新文件夹，此时你拥有两个独立工作目录：

  • glog_new：对应 main 分支（原仓库）

  • glog_featureA：对应 feature-A 分支（新工作树）

3. 日常并行开发

操作逻辑和单仓库完全一致，只是多了 “切换文件夹” 的动作：

  1. 用 VS Code 分别打开两个文件夹

  2. 在glog_featureA写 feature-A 代码，提交时直接git commit，不影响 main 分支

  3. 在glog_new修复 main 分支 bug，提交记录会同步到底层.git目录

  4. 拉取远程更新：在各自目录执行git pull即可

4. 删除无用工作树（正确姿势）

若 feature-A 开发完成，需按 “先删记录、再删文件夹” 的顺序操作，避免残留关联：

# 1. 进入原仓库目录

cd /Users/macm4/code/glog/glog\_new

# 2. 删除工作树关联记录（参数为新工作树路径）

git worktree remove ../glog\_featureA

# 3. （可选）手动删除空文件夹

rm -rf ../glog\_featureA

三、深入理解：prunable 是什么？怎么处理？

执行git worktree list时，可能会看到类似这样的输出：

/Users/macm4/code/glog/glog\_new  3cd64df \[main]

/Users/macm4/code/glog\_one       e30a69b \[one] prunable

其中prunable表示 “该工作树已失效，需清理”，这是 Git 对 “无法关联到工作目录” 的标记。

1. prunable 常见原因

  • 手动删除了工作树文件夹（如直接删掉glog_one）

  • 工作树关联的分支（如one分支）已被删除

  • 移动了工作树文件夹，未同步更新关联路径

2. 清理失效记录：git worktree prune

若确认该工作树无需保留，用以下命令清理prunable记录：

# 进入原仓库目录

cd /Users/macm4/code/glog/glog\_new

# 清理所有prunable失效记录

git worktree prune

执行后再用git worktree list查看，prunable记录会被移除，列表仅保留正常工作树。

四、真实场景案例：解决实际开发问题

案例 1：紧急修复 main 分支 bug，不中断 feature 开发

场景：正在glog_featureA（feature-A 分支）写代码，突然收到 main 分支紧急 bug 通知。

用 Git Worktree 处理流程：

  1. 不用暂停 feature-A 代码（无需stash），直接打开glog_new文件夹（main 分支）

  2. 快速修复 bug，执行git commit -m "fix: 紧急修复登录异常"

  3. 推送 main 分支到远程：git push origin main，通知运维部署

  4. 部署完成后，切回glog_featureA，继续开发 feature-A，无任何干扰

对比传统方案：若用单仓库，需先git stash暂存 feature 代码，切换到 main 修复，修复后再切回stash pop，若暂存记录多还可能冲突 ——Git Worktree 直接省掉这些步骤。

案例 2：移动工作树文件夹后，修复 prunable

场景还原：你之前为one分支创建了工作树/Users/macm4/code/glog_one，后来整理文件夹时，手动将其移到/Users/macm4/code/glog/目录下（新路径：/Users/macm4/code/glog/glog_one）。移动后执行git worktree list，发现该工作树显示旧路径且带prunable：

/Users/macm4/code/glog/glog\_new  3cd64df \[main]

/Users/macm4/code/glog\_one       e30a69b \[one] prunable  # 旧路径+失效标记

问题核心：Git Worktree 依赖 “双向链接”—— 工作树需知道主仓库在哪，主仓库也需知道工作树的路径。移动文件夹后，双向链接均失效，导致prunable。

完整修复步骤：

步骤 1：修复 “工作树→主仓库” 的链接

打开新路径下的.git文件（/Users/macm4/code/glog/glog_one/.git），确保内容指向主仓库的 worktree 目录：

# .git文件内容（需手动修改路径）

gitdir: /Users/macm4/code/glog/glog\_new/.git/worktrees/glog\_one

修改后，在glog_one目录执行git status，若能正常显示one分支，说明此链接已修复。

步骤 2：修复 “主仓库→工作树” 的链接

进入主仓库的 worktree 目录，修改gitdir文件（记录工作树路径）：

# 1. 进入主仓库的worktree子目录（对应one分支的记录）

cd /Users/macm4/code/glog/glog\_new/.git/worktrees/glog\_one

# 2. 查看当前记录的旧路径

cat gitdir  # 输出：/Users/macm4/code/glog\_one

# 3. 用文本编辑器打开gitdir文件，修改为新路径

/Users/macm4/code/glog/glog\_one

步骤 3：验证修复结果

回到主仓库目录，重新查看工作树列表：

cd /Users/macm4/code/glog/glog\_new

git worktree list

此时输出会显示新路径，且prunable标识消失：

/Users/macm4/code/glog/glog\_new  3cd64df \[main]

/Users/macm4/code/glog/glog\_one  e30a69b \[one]  # 正常状态

注意事项

若修复后仍显示prunable，检查两点：

  1. 路径是否完全正确（如少写目录、大小写错误）

  2. 关联分支是否存在（执行git branch查看，若one分支已删，需重新创建后再关联）

五、优缺点与适用场景

优点

  1. 并行开发无干扰：多分支代码分开存放，无需频繁stash/checkout

  2. 空间利用率高：共享.git目录，比克隆多仓库省空间

  3. 环境独立：各分支依赖、配置互不影响（如不同分支用不同 Node 版本）

  4. 命令兼容：新工作树中可执行所有 Git 命令，和原仓库无差异

缺点

  1. 需手动管理多文件夹（避免搞混分支对应关系）

  2. 移动 / 删除工作树后需修复链接，否则会出现prunable

  3. 仍占用少量额外空间（仅分支代码，非完整历史）

适合场景

  • 长期并行开发多个分支（如 feature 分支 + main 分支维护）

  • 频繁切换分支处理紧急需求（如开发中突然修 bug）

  • 需保留多分支独立依赖环境（如旧分支需兼容低版本依赖）

结语

Git Worktree 不是新功能，但却是 “解决多分支并行开发痛点” 的实用工具。它的核心是 “共享历史、独立工作目录”，理解 “双向链接” 原理后，无论是创建、删除还是修复prunable，都能轻松应对。

下次再遇到 “同时改两个分支” 或 “误移工作树” 的情况，别再依赖stash或多克隆了 —— 试试 Git Worktree，让多分支开发更清爽！