根据记录，手册页（index-pack) https://www.git-scm.com/docs/git-index-pack/1.5.5 states:
这是可能的git-pack-objects https://git-scm.com/docs/git-pack-objects/1.5.5构建“薄”包，其中根据包中未包含的对象以增量形式记录对象，以减少网络流量.
这些对象是预计出现在接收端并且它们必须包含在包中，以便该包是独立的且可转位的。
这样就完成了git push手册页 https://git-scm.com/docs/git-push/1.5.5 of the --thin option:
精简传输花费额外的周期来最大限度地减少要发送的对象数量，并用于较慢的连接
因此，在这种情况下，“慢速网络”是指您希望发送尽可能少的数据量的连接。
更多信息请访问 ”对于高延迟磁盘，Git 提取许多文件的速度很慢 https://stackoverflow.com/a/52452772/6309".
In 这个线程 http://lists.zerezo.com/git/msg671984.html, 雅库布·纳伦布斯基 https://stackoverflow.com/users/46058/jakub-narebski解释更多（在远程端和本地端使用 git gc 的上下文中）：
Git 进行增量化only在包文件中。
但是当你通过 SSH 推送时，git 会生成一个包文件，其中包含对方没有的提交，并且这些包是薄包，因此它们也有增量......
但远程端随后会向这些薄包添加底座，使它们成为独立的。
更确切地说：
在本地端：
git-commit创建松散（压缩，但未增量）对象。git-gc包装和增量。
在远程端（对于智能协议，即 git 和 ssh）：
git 创建thin包装，精致；
在远程端，git 要么通过添加基础对象（对象+增量）来使包变厚/自包含，要么将包分解为松散对象（对象）。
您需要远程服务器上的 git-gc 才能在远程端完全 deltify。但转移是完全的
德尔特化。
在远程端（对于哑协议，即 rsync 和 http）：
git 找到所需的包并将其整个传输。
所以情况就像在本地一样，但 git 可能会传输比实际需要的更多的内容，因为它传输的是完整的包。
上述问题与使用（或不使用）git push --thin: 什么时候用，什么时候不用？
事实证明，如果您希望 git 利用这些薄数据包，您确实需要仔细管理您的二进制对象：
- 只需复制旧文件名即可创建新文件名（因此使用旧的 blob）
- commit
- PUSH
- 复制真正的新文件
- commit
- PUSH.
如果省略第3步中间的PUSH，则“git push", nor "git push --thin”
可以意识到这个新文件可以在远程端“增量构建”（即使 git-gc 完全将其压缩在包中）。
事实上，精简包的工作方式是针对未包含在包中的基础对象存储增量。
那些未包含但用作增量基础的对象当前只是文件的先前版本，该文件是要推送/提取的更新的一部分。
换句话说，必须有同名的先前版本才能运行。
如果之前的提交有数千个文件需要测试，那么否则就无法扩展。
这些精简包是针对同一文件的不同版本而设计的，而不是针对内容几乎相同的不同文件。问题是决定将哪个首选增量基添加到对象列表中。目前仅考虑与正在修改的对象具有相同路径的对象。
