单仓库里目录很多，但手头只改其中一块时，可以试试 Git 自带的 sparse-checkout，减少工作区里无关文件。环境：Git 2.25+。
git clone --filter=blob:none --no-checkout <repo-url> project
cd project
git sparse-checkout init --cone
git sparse-checkout set services/api shared
git checkout main
这样工作区只展开 services/api 和 shared。后面要加目录，继续执行：
git sparse-checkout add services/web
它主要控制工作区内容，不等于权限隔离；需要完整历史时也还是会保留提交记录。老项目如果目录结构复杂，先看一下 Git 版本和 sparse-checkout 的模式差异，避免脚本在不同环境里表现不一致。
补充一个容易混淆的点：sparse-checkout 主要控制工作区里展开哪些目录，不会自动减少提交历史；--filter=blob:none 才是部分克隆，且需要服务端支持。另一个小坑是示例里的 main 要换成仓库实际默认分支名，否则最后一步可能直接报分支不存在。
离线 CI 这个提醒很关键。要避免构建阶段偷偷联网，可以在准备阶段先跑一遍依赖相关命令，把需要的 blob 预取完，再让正式构建使用网络隔离；同时把 GIT_NO_LAZY_FETCH=1 放进 CI 环境，漏掉的对象会更早暴露。这样 sparse-checkout 负责工作区范围，预取和禁用懒加载负责把网络行为变得可控。
Nathan03Lv1#3 离线 CI 这个提醒很关键。要避免构建阶段偷偷联网，可以在准备阶段先跑一遍依赖相关命令，把需要的 blob 预取完，再让正式构建使用网络隔离；同时把
GIT_NO_LAZY_FETCH=1放进 CI 环境，漏掉的对象会更早暴露。这样 sparse-checkout 负责工作区范围，预取和禁用懒加载负责把网络行为变得可控。
还有个容易漏掉的边界：init --cone 更适合按目录筛选；如果要精确到单个文件或复杂 glob，就得评估 --no-cone，它的模式规则更灵活，但后续维护也更容易踩坑。CI 里最好把 sparse-checkout 的规则当成配置一起评审，别只看最终工作区少了多少文件。