Git Worktree 实战指南：平行开发的秘密武器

Fri, 06 Mar 2026 04:20:00 +0800

前言

你是否经历过这样的场景？

当你正在为某个功能跑漫长的测试时，突然来了一个紧急的 bug 要修复，但你又不能随便动工作区的代码，因为测试还在进行。此时只能无奈地切换分支，导致 node_modules 需要重新安装，编译需要重新进行…

Git Worktree 就是来解决这个问题的。它允许你在同一个 Git 仓库中同时维护多个工作目录，每个目录可以检出不同的分支，彼此独立。

这篇文章将从理论到实战，深入讲解如何使用 Git Worktree 来优化你的开发流程。

什么是 Git Worktree？

基本概念

Git Worktree（工作树）是一个 Git 特性，允许你在同一个 Git 仓库中创建多个工作目录。

在没有 Worktree 之前：

一个仓库 = 一个工作目录
切换分支会改变当前工作目录的文件状态
如果当前工作目录有未提交的改动，切换分支可能很困难

有了 Worktree 之后：

工作树 vs 传统分支

常见误解： 工作树是对分支的替代

正确理解： 工作树是对分支的一种**“文件系统视图”**

分支：Git 中用来隔离开发路线的概念，存储在 .git/refs/heads/ 中
工作树：只是物理上创建了一个新的目录，让你能同时看到/编辑多个分支

分支的数量和数目都不会因为创建工作树而改变，工作树只是给了你一个新的"窗口"去访问这些分支。

为什么需要 Git Worktree？

常见应用场景

1️⃣ 场景：修复紧急 bug，不中断当前工作

你正在 feature/new-api 分支上开发新功能，代码还未提交。突然生产环境爆出一个 bug，需要立即修复。

传统做法：

# 代码还没 commit，必须先 stash
git stash

# 切回 main 分支
git checkout main

# 修复 bug，提交
git commit -m "fix: xxx"

# 切回开发分支
git checkout feature/new-api

# 恢复代码
git stash pop

问题：如果项目很大（如前端项目有巨大的 node_modules），即使只是切换分支也要重新安装依赖！

开发工具 on ShawnDeng's Tech Blog