针对海量不变二进制文件：Git LFS 与 Annex 选型咨询

一、其他可行方案 #

1. Git LFS 优化策略 #

• 分支归档+对象清理：将不再需要的旧版本二进制文件迁移至单独的归档分支，在主分支删除这些文件的引用。之后执行git lfs prune --unreferenced即可清理掉未被任何活跃分支/标签引用的LFS对象，解决HEAD引用无法清理的问题。
• 多存储后端分区：把当前在用的文件存到性能较好的LFS存储后端，旧归档文件转移到低成本的存储（如对象存储归档层），通过LFS的配置切换不同后端，避免主存储体积持续膨胀。

2. 制品库+Git元数据方案 #

放弃在Git中直接管理二进制文件，改用Artifactory、Nexus这类制品库存储二进制文件，Git仅保存文件的元数据（如版本标识、制品库下载路径）。发布时根据元数据从制品库拉取对应版本，既控制了Git仓库体积，也能通过制品库的多节点同步实现多位置发布。

3. 独立LFS仓库+Submodules #

将二进制文件单独托管到一个LFS仓库，主仓库通过Git Submodules引用该LFS仓库的特定版本。当旧版本不再需要时，可删除主仓库中对应的submodule引用，再对独立LFS仓库执行清理操作，实现体积管控。

二、Git Annex vs Git LFS：场景适配性对比 #

Git Annex 的优势（适配你的场景） #

• 按需删除能力：支持git annex drop命令删除本地和远端存储的文件对象（需配置存储后端的删除权限），从根本上解决仓库体积只增不减的问题。
• 存储路径灵活：支持相对路径配置存储位置，即使无法控制所有文件系统，只要存储位置邻近就能正常工作，适配你提到的环境限制。
• 存储后端多样性：支持本地目录、云存储、甚至自定义存储后端，比LFS的后端选择更丰富。

Git Annex 的劣势 #

• 学习成本高：Annex的命令逻辑和工作流比LFS复杂，团队需要额外的学习成本才能熟练使用。
• 工具链支持弱：主流CI/CD平台、代码托管服务对Git Annex的支持不如Git LFS成熟，可能需要额外配置适配。
• 大规模文件性能：在数千个大文件的场景下，Annex的批量操作效率可能不如LFS。

结论 #

如果你的核心需求是严格控制仓库体积（能删除旧文件）和灵活配置存储路径，Git Annex显然更适配；如果团队更看重工具链兼容性和低学习成本，则需要权衡后选择。

三、是否错误使用了Git LFS？ #

这取决于你的使用方式：

• 可能的误用场景：
  • 未做分支/引用管理：如果所有带时间戳的旧文件都保留在主分支的HEAD引用中，git lfs prune确实无法清理，这属于没有利用Git的分支策略来分离活跃文件与归档文件。
  • 未配置LFS生命周期：LFS本身支持清理未被引用的对象，但需要主动移除旧文件的Git引用（如从分支、标签中删除），如果没做这一步，就会导致体积持续膨胀。
• 非误用场景：
  如果你的业务要求所有历史版本的二进制文件必须在Git历史中保留引用，那LFS无法删除对象的特性是其设计局限，不属于误用——LFS的定位就是跟踪Git历史中的大文件，确保历史完整性，因此天生不支持“删除历史中存在的文件对象”。

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