Git只是部分添加了巨大的二进制文件

我想使用Git进行数据存储，自动工具将使用Git（因此速度并不重要）。但是，当我试图向git添加一个巨大的二进制文件（在我的例子中，它是一个大小为24.2GB的zip文件）时，它只是部分地做到了这一点

我的流程：

准备文件夹2个巨大的二进制文件只是为了测试

调用

git init

初始化git项目

git add-A-v-f

将所有文件添加到stage（日志显示，两个文件都已添加，没有错误或警告）

选中.git文件夹，它的大小只有41.6MB，看起来太小了，但让我们继续

git commit-m“initial commit”

进行提交（日志显示2个文件已更改，.git文件夹的大小仍然为41.6MB）

删除其中一个媒体

git reset——硬盘

——只恢复了222MB的二进制文件

Git版本：2.13.2.windows.1

系统：Windows Server 2016标准x64

Git具有所有默认配置

问题可能是什么？是否可以在不切换到git LFS或其他版本控制系统的情况下解决问题

我想使用Git进行数据存储，自动工具将使用Git（因此速度并不重要）

无论速度是否重要，Git都不是一个数据库或通用文件系统，试图像使用一样使用它通常会让所有人失望。这是一个很好的例子，在这个例子中，您尝试在通用文件系统中做一些完全合理的事情，这在您的Git构建中显然是被破坏的

处理非常大的文件是一系列非常脆弱的操作，这些操作很容易退化，并且经常被忽略，因为没有人检查数千兆字节的文件，因为它不善于处理它们

我猜不出你还会发现什么问题，但我怀疑会有一些问题。（特别是如果您试图将此推送到主机提供商。）

---

您的问题中没有提出任何问题，它读起来更像是一个bug报告。事实上，这就是问题所在-这是一个意外的错误-您应该在Git for Windows问题跟踪器上报告它。

您为什么要使用Git进行此操作？版本控制（这只是其中一种情况，以后还会有文本文件，必须显示更改，但在这种情况下，不应该有这么大的文件，但谁知道，我不会是最终用户）Git LFS现在不是一个选项Git不是为管理二进制文件而设计的，这就是LFS的用途。对于数十亿字节的文件，它甚至不是一个好主意。如果LFS不是一个选项，那么最好使用另一个存储系统，比如AWS S3或FTP服务器。另外，尝试使用

Git count objects-H-v

查看实际的数据存储库管理的对象的大小。@Derek-无论如何，知道Git为什么会这样做是非常有趣的。我的意思是-文件只是字节；为什么Git会突然截断它？Git中是否有一些硬编码限制？在这种情况下，最好知道。我甚至会说-它应该用大红色字母强调在用户手册中：“如果文件大小超过X，Git将损坏您的文件！”我更新了我的问题，并添加了一个真正的问题。但实际上是否有可能以某种方式避免这个问题，因为在同事的帮助下，现在切换到其他vcs太贵了。我发现了一个。看起来您在哪里拥有权限，这确实是一个Git for windows错误