我知道git LFS会让git在一个文本文件中存储一个字符串“pointer”，然后git LFS会下载这个目标二进制文件。这样，远程git服务器上的git repos就变小了。但是，git LFS仍然要存储二进制文件，所以在我看来，本地存储（在git lfs pull之后）没有什么不同，并且远程git LFS服务器数据加上远程git数据的总和仍然相似。
git LFS如何有效地跟踪二进制文件？

更新：不要使用git lfs。我现在建议 * 反对 * 在我们的免费GitHub仓库中使用git lfs

(See我的评论在接受的答案下面。）
我刚刚发现免费版的git lfs有such strict limits，它是无用的，我现在正在从我所有的公共免费仓库中删除它。请参阅此答案（Repository size limits for GitHub.com）并搜索“git lfs”部分。
在我看来，git lfs的唯一好处是，当你克隆一个repo时，它避免了一次下载大量的数据。就是这样！对于任何总内容大小（git repo +可能的git lfs repo）小于200 GB的repo来说，这似乎是一个非常小的好处，如果不是无用的话。使用git lfs所做的就是

1. make git checkout take forever (literally hours)（坏）
   1.让我的通常快速和离线的git命令，如git checkout现在变成了在线和慢速的git命令（坏），以及
   1.充当另一个GitHub服务来支付（坏）。
   如果你想用git lfs来克服GitHub的100 MB max file size limit，就像我一样，不要！你会run out of git lfs space almost instantly，特别是如果有人克隆或fork你的repo，因为这是对你的限制，而不是他们的限制！相反，“像tar plus split或split alone这样的工具，可以用来将一个大文件分割成更小的部分，例如每个90 MB”（source），这样您就可以将这些二进制文件块提交到常规的git存储库中。
   最后，GitHub上停止使用git lfs并完全释放空间的“解决方案”绝对是疯狂的！你必须删除整个repo！请在这里查看这个Q&A：How to delete a file tracked by git-lfs and release the storage quota?
   GitHub的official documentation证实了这一点（强调已添加）：
   从Git LFS中删除文件后，Git LFS对象仍然存在于远程存储中，并将继续计入Git LFS存储配额。
   要从仓库中删除Git LFS对象，请删除并重新创建仓库。删除仓库时，所有相关的issue、star和fork也会被删除。
   我不敢相信这甚至被认为是一个“解决方案”。我真的希望他们正在研究一个更好的解决方案。