静态站点或组件库上线前，常同时要改两条紧急分支：一条修生产环境 CSS，一条做下周落地页。再克隆一份仓库既占磁盘又费心力。Git worktree 让你在同一对象库上并行检出多个分支，特别适合把「第二台机器」换成可 SSH 的云 Mac mini，在上面跑 Safari 与构建，而笔记本只保留一个主克隆写代码。
为什么 HTML/CSS 团队用 worktree
传统流程——stash、checkout、pull、再跑一遍 npm install——往往只为了改十几行 hero 区 CSS，上下文全丢。worktree 让每个分支待在独立目录里、历史仍共享，于是 A 目录可以一直开着 npm run dev，B 目录并行 npm run build，不必来回切分支。
在 Apple Silicon 上，依赖安装依然耗时：即便 Git 对象共用，每个 worktree 下的 node_modules 对「Vite + Tailwind」这类栈也常占 250–400 MB。规划三个活跃树意味着仅依赖就可能逼近 1.2 GB，再加构建产物——云 Mac 磁盘宽裕时很轻松，256 GB 笔记本若还要装照片与 Docker 镜像就会吃紧。
对需要同时对照设计稿与 DOM 的前端，worktree 还能让「热修分支」与「特性分支」各用一套本地 URL，减少误把未合并样式提交到错误分支的概率。评审时也可以把两个目录的 diff 并排给设计师看，而不必反复切换检出。
日常必备命令
在主仓库路径下为兄弟目录增加检出：
git fetch origin
git worktree add ../site-hotfix origin/hotfix/css-hero
git worktree list合并完成后移除对应目录：
git worktree remove ../site-hotfix若提示有未提交改动，先提交或确认无用后再 --force。若曾手滑 rm -rf 删过目录，用 git worktree prune 清理元数据，避免 git worktree list 里出现幽灵条目。
工作树、全量克隆与独立仓库
| 方式 | Git 对象占用 | 复杂度 | 适用 |
|---|---|---|---|
| 第二次完整克隆 | 重复 .git | 低 | 物理隔离机器 |
| worktree | 共享对象库 | 中 | 同远端、多分支并行 |
| 独立仓库（fork） | 独立历史 | 高 | 供应商代码与主仓远端不一致 |
开发服务器、端口与 Safari 标签
每个 worktree 是独立根目录，可在一个里跑 npx vite --port 5173，另一个 --port 5174。请在 README 或团队文档写清：热修 → 5173，卡片特性 → 5174。远程会话里 Safari 固定标签页容易丢，可把两个 URL 存书签，或写个小脚本在起服务后 echo 链接。
若你同时用 SSH 跑命令、偶尔用 VNC 看像素，可参考 云 Mac 上 SSH 与 VNC 的对比，把长任务放在 SSH 会话，需要并排对比两个分支的 Safari 表现时再开图形。
端口冲突常见于忘了关旧进程：用 lsof -i :5173 找到占用者再结束，比盲目改端口更能避免 CI 与本地文档不一致。
删除目录前的清理清单
- 在 Git 托管平台确认分支已合并或废弃。
- 停掉 watch 进程（
Ctrl+C），避免文件句柄未释放。 - 优先
git worktree remove <路径>，少用手动rm -rf。 - 若已手动删除，检查是否残留
dist/、.vite缓存。 - 实验性安装过多时可跑
npm cache verify回收空间。
跳过第三步容易导致 git worktree list 与真实目录不一致，自动化脚本若带 30 秒 超时遍历树，会莫名失败——元数据和人类一样需要定期打扫。
Prettier、ESLint、Stylelint 的缓存常在各树自己的 node_modules/.cache；若把缓存目录硬链接共享，可能在某一分支升级插件大版本后污染另一分支的格式化结果。更稳妥是接受重复缓存，直到磁盘监控连续一周高于 85 % 再讨论统一缓存策略。
静态导出（Eleventy、Astro 静态模式）在大版本发布日可对每个树顺序执行 npm run build：四棵树若各开 八个 worker 并行，M4 Pro 上也可能 CPU 打满。可在 Node 启动参数加 --max-old-space-size=4096，并在 Console.app 关注是否出现内存压力日志。
为什么在租用 Mac 上跑 worktree
机房里的 Apple Silicon Mac mini 像共享构建柜：大家把分支推到同一台机，在 /Users/ci/sites/ 下按规范路径 git worktree add，评审完再删。笔记本保留一个主克隆写逻辑；重型并行安装放在按时计费的云端，磁盘与电费压力都更小。
若 SSH 密钥与 config 尚未理顺，请先读 远程 Mac 配置指南，再写自动化添加 worktree 的脚本——稳定的认证比花哨的目录命名更重要。
成熟团队会把 git worktree add 包进 Makefile 或三十行以内的 shell：顺带 npm ci 并打印 dev URL。路径可统一为 /var/tmp/worktrees/$BRANCH_SLUG，slug 截断到 48 个字符，避免 Webpack 写深层临时文件时撞上 macOS 路径长度上限。
子模块与 worktree 要格外小心：每棵树可能都要单独 git submodule update --init。使用 Git LFS 的资源仓库记得每树执行 git lfs pull，否则会出现「CSS 构建成功但 Safari 里 hero 视频 404」这类怪问题。
CI 发预览链接时，在 Slack 里同时标注 worktree 路径（例如 热修 → ~/wt/hero），评审者 SSH 进去不会找错目录。每人省三分钟上下文切换，四个人一轮评审就能抵消不少租赁分钟成本。
可再配一个 worktree-health.sh，输出磁盘剩余、活跃 node 进程与各 dev server 日志最后五行，用 cron 或 LaunchAgent 每 15 分钟 跑一次；确认没有孤儿 webpack 再 git worktree remove --force，避免误杀仍在写的进程。
共享主机上每个 worktree 继承同一套凭据助手，若外包人员曾登录 shell，合并后记得轮换部署密钥。各树 .env.local 建议 chmod 600，不要把密钥复制到多个分支目录——未合并的热修树在删除前始终可读。
大改版前可用 tmutil localsnapshot 做本机快照，或给 dist/ 打个 tarball，避免某次 CSS purge 脚本误伤所有活跃树时无处回滚。
常见问题
一台 Mac 上建议保留几个 worktree？
在 256 GB 磁盘上多数团队把活跃 worktree 控制在三到六个之间。每个工作树仍有独立工作区与 node_modules，除非使用高级工具共享依赖，建议每周用 df -h 观察空间。
worktree 会共享 Git 对象吗？
会。同一仓库下的多个 worktree 共用一份 .git 对象库，比重复 git clone 更省空间；但 node_modules 不会自动共享。
能同时跑两个 Vite 吗？
可以，为每个目录显式指定端口，例如 --port 5173 与 --port 5174，并在团队文档里写明映射。Safari 可同时打开两个 localhost 做视觉对比。
Git worktree 不能替代清晰的分支命名，但能去掉「反复 checkout」的摩擦；与一台常开、环境接近生产的 Mac mini 搭配时，特别适合在发布周并行多条 HTML/CSS 车道。按日租用云端算力，高峰多加几棵树，发布结束后删掉 worktree、缩减开支，比为峰值单独采购机器更灵活。
并行分支需要并行磁盘空间
租用云 Mac mini，共享 worktree、Safari 评审与长时间 dev server。先选区域，再按帮助中心完成 SSH 与密钥配置。