如何缩减Azure DevOps仓库大小？提交历史清理及优化方案咨询

一、清理提交历史的靠谱方法 #

目前官方最推荐的是git filter-repo，比老旧的git filter-branch效率更高、稳定性更好，具体操作步骤：

• 先安装git filter-repo（部分系统需单独安装，比如通过pip）
• 移除历史中的特定大文件：git filter-repo --path <要删除的大文件路径> --invert-paths
• 压缩仓库冗余数据：git reflog expire --expire=now --all && git gc --prune=now --aggressive
• 强制推送到远程仓库：git push --force（⚠️ 重要提示：这会彻底重写远程仓库历史，必须通知所有开发者重新克隆仓库，否则会引发严重冲突）

如果不需要完整提交历史，也可以直接创建浅克隆仓库：
git clone --depth <保留的提交次数> <远程仓库地址>
将这个浅克隆作为新的远程源即可，缺点是会丢失早期提交历史，适合不需要追溯旧代码的场景。

二、清理提交历史能解决体积与性能问题吗？ #

这得看仓库体积过大的根源：

• 如果是历史中堆积了大量已删除的大文件（比如安装包、日志、二进制资源），清理历史确实能大幅缩小仓库体积，克隆、构建时的文件读取速度会明显提升，部署延迟问题也能得到缓解。
• 如果是当前代码本身就包含大量未被过滤的大文件（比如没加入.gitignore的Salesforce静态资源），仅清理历史效果有限，需要配合完善.gitignore规则，把不必要的文件排除在仓库外。

三、更优的替代方案 #

针对你这种多部署任务的Salesforce场景，以下方案更具可持续性：

• 拆分仓库：按部署任务或业务模块拆分仓库，比如把不同环境的部署代码、不同业务线的模块分开维护。每个小仓库体积更小，构建部署仅处理当前任务的代码，无需加载整个大仓库的内容。
• 完善.gitignore规则：将Salesforce开发中产生的临时文件、日志、未打包的静态资源、本地配置文件等都加入.gitignore，防止这类文件不断累积增大仓库体积。
• 使用Salesforce DX做模块化部署：利用scratch orgs和sfdx-project.json/package.xml仅打包当前部署所需的元数据，无需处理整个仓库的内容，减少构建时的文件处理量。
• 定期维护仓库：每隔一段时间运行git gc --aggressive压缩仓库，清理冗余对象和引用；同时检查历史记录，及时移除意外提交的大文件。

内容的提问来源于stack exchange，提问作者Kenruth