迁移至Git后如何处理CI流程使用的Documentation目录问题

可选方案按推荐优先级排序如下： #

方案1：Git稀疏检出（Sparse Checkout），零仓库改造优先选择

不需要拆分现有仓库结构，完全满足需求：

• 开发侧配置默认稀疏检出规则：Git 2.37+版本可以直接用git clone --sparse命令初始化克隆，默认排除Documentation目录，拉取的压缩包大小仅为源码对应的135MB左右，完全不会干扰开发日常使用。如果个别开发需要临时查看文档，修改本地稀疏检出规则重新拉取即可，操作门槛极低。
• CI侧不需要做任何配置改动，原有构建流程直接拉取全量代码即可正常获取Documentation目录，完全不会影响打包流程。

方案2：大文件存入Git LFS，适合二进制文件频繁更新场景

如果后续Documentation目录还会持续新增PDF等大体积二进制文件，这个方案的长期维护性更好：

• 把Documentation目录下的所有大文件配置为LFS跟踪对象，开发人员默认克隆时只会拉取LFS指针文件，整个仓库拉取体积仅为135MB左右，完全无感知。
• CI侧仅需要在原有拉取代码步骤后增加一行git lfs pull命令即可获取所有文档实际文件，构建逻辑改动极小。

方案3：独立仓库+优化版子模块，仅需隔离权限时选择

如果确实需要把文档和源码的版本管理、权限完全拆分，可以优化你想到的子模块方案降低使用成本：

• 给团队配置全局Git参数submodule.recurse = false，开发人员默认克隆时不会自动拉取文档子模块，拉取体积仅为源码的135MB左右，不需要开发手动处理子模块逻辑。
• CI侧拉取代码时增加--recurse-submodules参数即可同时拉取文档子模块，构建流程仅需调整一行命令即可。

内容的提问来源于stack exchange，提问作者C.M.