由于二进制文件,无法推送到 Git

big*_*ode 6 git binaryfiles github command-line-interface

因此,由于某些二进制视频文件,我一直在将问题推送到我一直在工作的主分支。当我第一次尝试推送它们时,这些文件太大了。所以我将它们从我正在处理的项目目录中删除。但是现在,当我从第一次初始推送开始尝试推送时,它会返回此错误消息。

Compressing objects: 100% (38/38), done.
Writing objects: 100% (39/39), 326.34 MiB | 639.00 KiB/s, done.
Total 39 (delta 16), reused 0 (delta 0)
remote: error: GH001: Large files detected.
remote: error: Trace: b7371dc6457272213ca1f568d9484c49
remote: error: See http://git.io/iEPt8g for more information.
remote: error: File themes/SomeFile/uploads/me_582610_mountain-river.mov is 315.08 MB; this exceeds GitHub's file size limit of 100 MB
To git@github.com:UserName/Project.git
Run Code Online (Sandbox Code Playgroud)

它说的文件太大,似乎仍然存在于我的目录中,甚至在我的计算机上实际上根本不存在。我把它彻底删除了。这里有什么问题?这是我第一次遇到这个问题。我去了引用的 Git 站点寻求支持,https://help.github.com/articles/working-with-large-files/,然后运行它git rm --cached me_582610_mountain-river.mov并返回消息fatal: pathspec 'me_582610_mountain-river.mov' did not match any files

请任何帮助将不胜感激!

Ric*_*ner 3

请记住,默认情况下,您提交给 git 的所有内容都会保留在您的存储库中 - 即使您在以后的提交中“删除”它

\n\n

GIT 的弱点之一(以及其他 DVCS)是它不能很好地处理大型二进制文件。许多想要对大量大型二进制文件进行版本控制的团队/人员更喜欢集中式 VCS,例如PerforceSubversion等。人们可以更好地控制下载存储库的哪一部分以及存储库中保留了先前提交的多少个版本。

\n\n

对于您的问题:您有一个存储库,您之前已向其中提交了一个大型二进制文件。即使您随后从存储库中“删除”了它,该文件仍然保留。要从存储库中完全删除它,您必须进行一些手术,物理销毁添加该文件的原始提交,然后重写存储库中的每个后续提交!

\n\n

根据关于删除对象的 GIT 文档重点是我的):

\n\n
\n

Git 有很多很棒的东西,但一个可能导致问题的功能是 git 克隆会下载项目的整个历史记录,包括每个文件的每个版本。如果整个内容都是源代码,这很好,因为 Git 进行了高度优化,可以有效地压缩该数据。但是,如果有人在项目历史记录中的任何时刻添加了一个大文件,则所有时间的每个克隆都将被迫下载该大文件,即使它在下一次提交时已从项目中删除

\n
\n\n

问题的解决方案不是一个简单的过程,而是具有破坏性的(因为它基本上重写了包含有问题文件的提交后的每个提交),并且在上面的链接中有很好的记录,我鼓励您阅读在更新您的官方树之前,请多次练习并在树的本地副本上进行练习。

\n\n

谨慎行事!

\n\n
\n

如果您在导入后立即执行此操作,那么在任何人开始基于提交进行工作之前,您\xe2\x80\x99就很好\xe2\x80\x94,否则,您必须通知所有贡献者,他们必须将他们的工作重新建立在您的基础上。新的提交。

\n
\n\n

坦率地说,大约一年前,当我使用自己的存储库(即不与其他人共享)执行此操作时,我选择将当前的代码库复制到一个新文件夹并从中创建一个新的 GIT 存储库,而不是尝试重写我所有的历史记录、包文件等。当时,丢失历史记录对我来说并不是一个主要问题。

\n\n

祝你好运!

\n