Git
Git Worktree 实战指南:平行开发的秘密武器
前言
你是否经历过这样的场景?
当你正在为某个功能跑漫长的测试时,突然来了一个紧急的 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),即使只是切换分支也要重新安装依赖!