monorepo 场景下的稀疏检出与多工作树协作

学完这篇你会掌握什么

• 理解 monorepo 场景下的稀疏检出与多工作树协作 的核心作用和适用场景
• 掌握 monorepo 场景下的稀疏检出与多工作树协作 的基本用法和常用参数
• 在 monorepo 场景里，用 sparse-checkout 和 worktree 限定工作范围，降低上下文负担并支持并行任务。
• 理解 一个常见场景 相关的概念
• 掌握 一条可执行流程 相关的操作
• 知道在什么场景下使用该命令，什么场景下避免使用

monorepo 最常见的问题不是 Git 失效，而是工作范围太大。

这时可以把两个能力结合起来：

• sparse-checkout：只拉起当前需要的目录
• worktree：为并行任务开多个独立工作副本

先想一个问题

你和团队正在协作一个项目，分支越来越多，合并越来越频繁，但缺少一个稳定的协作节奏——每个人都在用自己的方式同步代码，冲突越来越频繁。

一个常见场景

完整 Monorepo

packages/frontend/packages/backend/packages/shared/docs/infra/

→sparse-checkout + worktree

限定工作空间

wt-frontend/ → 只检出 frontend + sharedwt-backend/ → 只检出 backend + shared每个 worktree 只包含相关目录

cone 模式下 sparse-checkout 性能更好。配合 worktree 实现真正的并行 monorepo 开发。

你只改前端应用，但仓库里还有后端、脚本、基础设施和大量共享包。
如果每次都把整棵树都拉起来，成本会很高。

一条可执行流程

git sparse-checkout init --cone
git sparse-checkout set apps/web packages/ui
git worktree add ../repo-hotfix hotfix/login-fix

这样你可以：

• 在当前工作树处理主任务
• 在另一个 worktree 里处理热修
• 同时让当前工作区范围保持更小

和 submodule 的边界

如果仓库本身就是 monorepo，优先考虑 sparse-checkout / worktree。
如果你管理的是独立仓库依赖关系，才更可能落到 submodule。

一个原则

在大型仓库里，Git 工作流优化的关键不只是命令更高级，而是把“我现在真正要改的范围”压缩到足够清楚。

给你的练习

1. 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
2. 尝试该命令的不同参数选项，对比输出结果的差异
3. 模拟一个需要使用该命令的实际场景，完整走一遍操作流程

延伸阅读

沿着同一主题继续深入：

• Merge Queue 工作流
• 多人协作时的同步节奏
• 开源贡献 / fork + PR 完整提交流程