化繁为简的企业级 Git 管理实战（五）：二进制大文件的版本控制

毫无疑问，Git 很是适合用于代码文件的版本控制。对于纯代码仓库，因为每次实际提交都是增量内容，即便仓库经历了几十次提交，整个仓库的大小每每都不会大幅增长。

而对于存在二进制文件的仓库，状况就变了：Git 并不能很好地支持二进制文件的增量提交，每次更新一个二进制文件，就至关于把这份文件的完整内容再往仓库里扔。长此以往，这个仓库就会变得很是大，影响代码拉取速度。

举一个实际的例子，为了加快应用的构建速度，咱们团队的框架先会编译成 SDK ，再交由上层构建应用。框架 SDK 也是一个独立的 Git 仓库，里头包含了大量的二进制包：

由于框架也有多个分支，每一个分支的迭代速度比较快，SDK 仓库的体积在三个月的时间内就膨胀到了 1G 。

如此庞大的仓库体积让第一次拉代码的同事叫苦连天。一次全新的 clone ，即便拉取速度达到了 5.01 MB/s，在 framework 这个模块上就须要花上大约 7 分钟的时间：

当不少人同时拉代码时，还有很大几率由于 HTTP 超时而拉取失败：

为了解决这个问题，我前后尝试了几种方案。

（舒适提示：请点击左下角【阅读原文】阅读完整的文章。）

本文分享自微信公众号 - HaHack（gh_12d2fe363c80）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。