核心用法
Git Worktrees 是一项被严重低估的 Git 原生功能，允许在单一仓库上维护多个独立的工作目录，每个目录指向不同的分支。与传统 git checkout 切换分支不同，worktree 实现了真正的并行开发——你可以同时在 main 分支运行生产环境，在 feature/x 开发新功能，在 hotfix/y 修复紧急问题，三者互不干扰。
本 skill 的核心价值在于标准化流程：
1. 智能目录选择：优先使用项目既有的 .worktrees/ 或 worktrees/ 目录，其次读取 CLAUDE.md 配置，最后询问用户偏好
2. 安全验证机制：强制验证目录是否被 .gitignore 忽略，防止 worktree 内容意外提交到仓库
3. 自动项目初始化：检测 package.json、Cargo.toml、pyproject.toml、go.mod 等文件，自动执行依赖安装
4. 基线测试验证：在正式开始开发前运行测试套件，确保新分支起始于健康状态
显著优点
- 零上下文切换成本：不再需要
git stash来回保存进度，每个功能都有独立完整的工作空间 - IDE 友好：可同时用多个 IDE 窗口打开不同 worktree，调试多分支交互场景极为便利
- CI/CD 亲和：worktree 本质是标准 Git 仓库，与现有工具链完全兼容
- 磁盘高效：通过 Git 的对象共享机制，多个 worktree 几乎不重复占用存储
- 安全兜底：内置的
git check-ignore验证和测试基线检查，避免常见陷阱
潜在局限
- 路径依赖：部分构建工具对绝对路径敏感，跨 worktree 的缓存可能失效
- 子模块复杂度：若项目使用 Git 子模块，worktree 的配置需要额外注意
- IDE 索引：大型项目在多个 worktree 同时打开时，IDE 的索引和搜索可能产生干扰
- 学习成本：团队成员需要理解 worktree 概念，与传统分支切换习惯形成对比
适合人群
- 需要同时维护多个长期功能分支的中大型团队
- 频繁进行代码审查、需要在 PR 分支与主分支间快速切换的开发者
- 运行耗时测试套件时，希望在另一分支继续工作的场景
- 追求"可重现开发环境"的 DevOps 实践者
常规风险
| 风险场景 | 缓解措施 |
|---------|---------|
| worktree 目录被误提交 | skill 强制 `git check-ignore` 验证，未通过时自动修复 `.gitignore` |
| 分支删除后残留空目录 | 配对 skill `finishing-a-development-branch` 负责清理 |
| 磁盘空间意外增长 | 定期 `git worktree prune` 清理失效引用 |
| 测试基线失败仍继续开发 | 明确报告失败并请求用户确认，禁止静默跳过 |
本 skill 的设计体现了"约定优于配置"的工程哲学——通过合理的默认值和强制检查，将 Git worktree 的高级能力封装为可安全复用的标准化流程。