branch vs worktree

branch vs worktree

 

 

 

 

这是一个非常经典的问题，特别是在使用 Git 进行并行开发时。简单来说，Branch（分支）是逻辑上的概念，而 Worktree（工作树）是物理上的概念。

你可以把它们的关系理解为：Branch 是你想要走的“路”，而 Worktree 是你脚下踩的“地”。

为了让你更直观地理解，我为你整理了一个核心对比表，随后我会详细拆解它们的区别和协作方式。

🆚 核心对比：Branch vs Worktree

维度	Branch (分支)	Worktree (工作树)
本质	逻辑指针。指向某个提交（Commit）的轻量级引用。	物理目录。包含实际文件、文件夹的工作空间。
解决痛点	解决代码版本的隔离问题（比如开发新功能不影响主代码）。	解决开发场景的并行问题（比如同时修Bug和写新功能）。
操作体验	在同一个目录下，通过 git checkout 或 switch 切换，文件会变来变去。	在不同的文件夹下，同时打开多个窗口，互不干扰，文件各改各的。
存储方式	存储在 .git/refs 中，占用空间极小。	每个 Worktree 都有独立的文件夹，但共享 .git 对象库（节省磁盘空间）。

---

💡 深度解析：为什么你需要区分它们？

1. Branch：时间的魔法

Branch 就像是电影胶卷的不同剪辑线。

• 你只有一个屏幕（工作目录）。
• 当你切换到 main 分支，你看到的是稳定版代码；切换到 feature 分支，你看到的是新功能代码。
• 局限性： 传统模式下，Git 强迫你一次只能在一个分支上工作。如果你正在写一半的功能，突然要修一个紧急 Bug，你必须先把当前的修改藏起来（git stash），切回去修 Bug，修完再切回来恢复现场。这非常打断思路。

2. Worktree：空间的魔法

Worktree 就像是给你的电脑增加了显示器，或者直接克隆了另一个工位。

• 它允许你为同一个仓库创建多个“分身”目录。
• 优势： 你可以在 /path/to/project-main 里继续写你的复杂功能，同时在 /path/to/project-hotfix 里从容地修复紧急 Bug。
• 关键点： 这两个目录虽然看起来像复制了两份，但它们底层共享同一个 Git 数据库（.git/objects）。这意味着你不需要重新下载历史数据，既快又省硬盘空间。

---

🛠️ 实战场景：什么时候用哪个？

场景 A：普通的线性开发

• 只用 Branch。
• 你做完手头的事，提交代码，然后切换到下一个任务。这是最标准的流程，不需要引入 Worktree 增加复杂度。

场景 B：突发任务打断（最推荐用 Worktree）

• 现状： 你在 feature-A 上改了一堆文件，还没写完，不想提交（因为代码很乱）。
• 突发： 线上出了严重 Bug，需要马上基于 main 分支修复。
• Worktree 解法：
  1. 在项目根目录执行：git worktree add ../project-hotfix main -b fix-bug
  2. 这会创建一个新文件夹 ../project-hotfix，里面是干净的 main 分支代码。
  3. 你去新文件夹修 Bug、测试、提交。
  4. 修完后，删除这个 worktree，原来的开发环境完全没动过。

场景 C：代码对比或 Review

• Worktree 解法： 你想看 v1.0 版本和 v2.0 版本的某个文件具体差别。与其切来切去记不住，不如开两个 Worktree，左边屏幕放 v1.0，右边屏幕放 v2.0，直接对照查看。

---

🚀 常用命令速查

如果你决定尝试 Worktree，这几个命令就够用了：

1. 创建一个新的工作树（在当前目录的上一层创建名为 project-hotfix 的文件夹，并关联 main 分支）：

   git worktree add ../project-hotfix main
   

2. 查看所有工作树（看看你现在开了几个“分身”）：

   git worktree list
   

3. 删除工作树（任务完成后，清理掉这个文件夹和关联）：

   git worktree remove ../project-hotfix
   

总结建议：
不要把它们看作对立的选项。Branch 是基础，Worktree 是增强工具。 当你在同一个仓库需要同时处理两件不同的事情时，Worktree 就是那个能让你从“频繁切换”的痛苦中解脱出来的神器。