我之前在几个数据密集型项目里碰到过几乎一模一样的问题，给你分享几个实际用过的可行方案，先从你问的Git LFS说起：

Git LFS 是否适用你的场景？ #

首先明确：Git LFS完全可以解决你的场景。很多人以为LFS只针对单个超大文件，但其实它的核心价值是把二进制文件从Git仓库剥离，存到外部存储，仓库里只保留小体积的指针文件。哪怕你的单个文件不大，但总容量GB级、不常变更的二进制文件，刚好符合LFS的适用场景——既避免了Git仓库臃肿，又能通过Git的工作流来追踪这些文件的版本（比如什么时候更新了一批辅助文件）。

但问题是你公司的Stash不支持LFS，那咱们就看替代方案：

替代方案（无需Git LFS支持） #

1. 外部存储 + 同步脚本 #

这是最容易落地的方案：

• 把所有辅助文件存到公司内部的共享存储（比如NAS、内部对象存储服务），按项目/版本分类存放，比如/shared-data/project-A/v1.0/、/shared-data/project-A/daily/（专门放每日新增的气象数据）。
• 在代码仓库里加一个setup-data.sh（或Python脚本），脚本里定义好需要拉取的文件路径、版本标识。克隆仓库后，运行脚本就能自动从共享存储拉取对应版本的辅助文件；对于每日新增数据，可以写个定时任务（比如cron），每天自动同步最新的气象数据到本地。
• 可以给辅助文件加哈希校验，脚本里先检查本地文件的哈希和存储端的是否一致，避免重复下载，节省带宽。

2. 独立Git仓库 + 子模块（Submodules）+ 稀疏检出 #

如果你们不想依赖外部存储，用Git本身也能搞定：

• 建一个专门的数据仓库，只存这些辅助二进制文件。因为这些文件不常变更，即使总容量大，Git的增量拉取只会下载变更的部分，日常使用负担不大。
• 在主代码仓库里用git submodule add关联这个数据仓库，然后配置稀疏检出（sparse checkout），这样克隆主仓库时，可以只拉取数据仓库里当前需要的目录（比如不需要历史所有版本的气象数据，只拉最近30天的）。
• 对于每日新增数据，直接往数据仓库里提交新增文件，团队成员只需运行git submodule update --remote就能同步最新数据。

3. DVC（数据版本控制工具） #

这个是针对数据科学/数据密集型项目的专用方案，完美匹配你“数据持续增长”的需求：

• DVC和Git深度集成，它会把数据存到你指定的外部存储（本地共享目录、NAS都可以），Git仓库里只存DVC的元数据文件（很小）。
• 它支持增量同步，每日新增的气象数据只需要同步新增部分，不用每次拉全量；还能给数据打版本标签，方便回滚到历史数据版本。
• 不需要服务器支持LFS，只要团队能访问共享存储就能用，上手成本也不高，和Git的命令风格很像。

4. 本地缓存 + 配置文件 #

如果团队内部有统一的共享文件服务器，这个方案最轻量化：

• 在项目根目录加一个data-config.yaml，里面记录辅助文件的共享路径、版本号。
• 写一个简单的初始化脚本，读取配置文件，检查本地data/目录下的文件是否完整，如果缺失就从共享路径复制过来。
• 每日新增数据可以让脚本定时去共享路径的“每日更新”目录里同步最新文件，或者手动触发。

总结 #

如果之后公司升级了BitBucket支持LFS，那LFS是最贴合Git工作流的方案；当下的话，优先推荐DVC（适合数据持续增长的场景）或者外部存储+同步脚本（最快落地），根据你们团队的技术栈和现有基础设施来选就行。

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