git branch 和 git worktree 常被混淆但它们在 Git 的底层逻辑中处于完全不同的维度。一句话概括分支是“逻辑指针”而 worktree 是“物理副本”。本质区别核心维度· Git Branch分支是一个轻量级的“移动标签”。它仅仅是指向某个提交对象Commit ID的指针存储在 .git/refs/heads/ 下。它不包含任何文件内容切换分支本质是改变 HEAD 指针的指向并更新工作区文件。· Git Worktree工作树是一个独立的“工作目录副本”。它允许你在同一个仓库下同时检出多个分支到不同的物理文件夹中。每个 worktree 都拥有自己独立的 HEAD、index暂存区和工作区文件。实现原理与底层机制底层存储结构· Branch存储在 .git/refs/heads/branch_name内容是一个 40 位的哈希值指向 Commit。切换分支时Git 只需修改 .git/HEAD 文件的内容如 ref: refs/heads/main。· Worktree主工作区在 .git/ 同级目录。新增的 worktree 存储在 .git/worktrees/unique_id/ 下。这个目录包含· HEAD指向当前检出的分支· index独立的暂存区文件· commondir指向主 .git 目录的路径· locked防止冲突或误删资源占用与共享· Branch几乎零成本仅 41 字节的文件。创建速度极快因为只是写一个文件。· Worktree硬盘成本较高需要完整复制工作目录的文件树但对象库完全共享。所有 worktree 共用 .git/objects对象数据库和 .git/refs引用库。这意味着在不同 worktree 中切换不需要重新下载对象且 git gc 统一管理所有引用。切换与并发机制· Branch切换时Git 会比较目标分支和当前分支的 Commit 树然后删除所有旧文件并写入所有新文件耗时取决于文件差异大小。且切换时不允许未提交的改动跨分支冲突除非使用 stash。· Worktree由于物理隔离允许同时打开多个终端在不同的文件夹中操作不同的分支且互不干扰。例如在 project-hotfix/ 修 Bug同时在 project-feature/ 开发新功能无需 stash 或 clone。关键差异速览表维度 Git Branch Git Worktree本质 可变指针引用 物理工作目录 独立暂存区存储位置 .git/refs/heads/ .git/worktrees/ 外部文件夹创建成本 极低写文件 较高复制工作树文件但共用对象切换速度 快仅更新变动文件 无需切换直接换文件夹分支共存 同一时刻只能检出 1 个主工作区 同一时刻可检出 N 个不同分支暂存区 共享 1 个 index 文件 每个 worktree 有独立的 index未提交改动 切换受阻需 stash 互不影响无需 stash适用场景建议· Branch日常单线程开发、代码审查、合并操作。· Worktree需要并行处理紧急热修复与长期特性开发时或者你想保留当前工作区不变同时又想快速验证另一个分支的编译结果时避免频繁 stash 和重新编译。好的为了更直观地体现它们在底层存储和操作流程上的差异我准备了两个文本流程图。底层存储与架构对比“逻辑指针” vs “物理副本”【Git Branch】 【Git Worktree】 (轻量指针) (独立副本) .git/ 仓库目录 .git/ 仓库目录 (共享) ┌─────────────────┐ ┌─────────────────────┐ │ refs/heads/ │ │ objects/ (共享) │ ◄───┐ │ ├─ main ──────│ 指向 Commit A │ refs/ (共享) │ │ │ └─ feature ───│ 指向 Commit B │ worktrees/ │ │ (共用对象库) └─────────────────┘ │ ├─ hotfix/ │ │ │ │ ├─ HEAD (独立) │ │ HEAD (指针) │ │ ├─ index (独立) │ │ │ │ │ └─ commondir ────┼─────┘ ▼ │ └─ feature-x/ ... │ ┌─────────────────┐ └─────────────────────┘ │ 当前工作区文件 │ (只有1份) │ └─────────────────┘ ▼ ┌─────────────────────┐ │ 外部文件夹1: hotfix │ (物理文件) └─────────────────────┘ ┌─────────────────────┐ │ 外部文件夹2: feat-X │ (物理文件) └─────────────────────┘切换与并行操作流程对比当你进行分支切换或新增工作区时Git 内部的运作机制完全不同【操作切换分支 (git checkout branch-B)】 【操作新增工作区 (git worktree add ./xxx)】 用户发起指令 用户发起指令 │ │ ▼ ▼ Git 读取目标指针 Git 创建外部目录 (./xxx) │ │ ▼ ▼ 比较当前 Commit(A) 与目标 Commit(B) 在 .git/worktrees/ 下创建专属文件夹 │ │ ▼ ▼ ┌───────────────────────────┐ ┌──────────────────────────────┐ │ 删除 A 对应的所有旧文件 │ │ 生成独立的 HEAD 和 index 文件│ │ 写入 B 对应的所有新文件 │ │ (暂存区完全隔离) │ │ (耗时取决于文件差异大小) │ └──────────────────────────────┘ └───────────────────────────┘ │ │ ▼ ▼ 通过硬链接/复制填充工作目录 修改 .git/HEAD 指向 B │ │ ▼ ▼ 所有新目录共享同一套 .git/objects 切换完成 (瞬间完成无需重新下载) ⚠️ 若有未提交改动切换会报错 ✅ 原有工作区纹丝不动直接切入并发场景时序图直观感受差异在同一个仓库下如果你同时修改两个分支的代码两者的表现截然不同【Git Branch 单线程模式】 【Git Worktree 并行模式】 时间轴 时间轴 │ │ ├─ 在 main 分支写代码 (未提交) ├─ 终端1: 在 main/ 文件夹写代码 │ │ ├─ 突发紧急Bug ├─ 终端2: 直接在 hotfix/ 文件夹 │ │ (完全独立无需切换) ├─ 尝试切到 hotfix 分支 │ │ ❌ Git 报错: ├─ 终端1 继续写 main 功能 │ Please commit or stash... │ ├─ 终端2 修复 hotfix 并提交 │ │ ├─ 被迫执行 stash 暂存改动 ├─ 终端1 提交 main 功能 │ 或 commit 提交 │ ✅ 两个分支互不阻塞无需 stash │ │ ├─ 切到 hotfix 修复 │ 原理每个文件夹有独立 index │ │ 和 HEAD互不干扰。 ├─ 切回 main 继续开发 │ │ (需重新加载工作区文件) │ └─ 结束 └─ 结束 总结一句话流程图Branch 你只有 1 台工位 (工作区)换项目时必须把桌面清空(stash)再搬新文件(checkout)。 Worktree 你申请了 N 台工位 (文件夹)每台放不同项目想干哪个直接走过去坐下就干互不影响。