检测到Git大文件 [英] Git Large files detected

问题描述

我通过使用JMeter执行了一些负载测试，然后试图通过执行来检查我的项目到git中

  git add。 
 git commit -mmessage
 git push 
  

message

 计数对象：13，完成。 
使用多达8个线程的增量压缩。 
压缩对象：100％（13/13），完成。 
写作对象：100％（13/13），50.13 MiB | 13.42 MiB / s，完成。 
总计13（delta 8），重用0（delta 0）
 remote：错误：GH001：检测到大文件。 
 remote：error：文件java_pid32554.hprof是412.89 MB;这超过了GitHub Enterprise的文件大小限制100.00 MB 
到https://github.dev.myc.com/p/p.git 
！ [远程拒绝]功能/分支 - >功能/分支（预接收钩拒绝）
错误：未能推送一些文件到'https://github.dev.myc.com/p/p.git'
  

要解决此错误，我做了以下操作：

  git rm java_pid32554.hprof $ b $ r rm java_pid32554.hprof 
 added * / *。hprof to .gitignore 
  

现在我可以看到从本地文件系统中删除了有问题的文件。为了确保我也做了搜索

  MacBook-Pro：p（功能/分支>）$ sudo find / -name java_pid32554 .hprof 
密码：
 find：/ dev / fd / 3：不是目录
 find：/ dev / fd / 4：不是目录
 MacBook-Pro：p（功能/分支>）
  

所以文件确实不见了。

现在，当我尝试

git push

时，它再次给出相同的错误信息....即使该文件被删除。

我不会将此问题标记为

我的问题提出了git的直接错误消息，下面的答案更清晰直接。另一个线程混杂着不同类型的解决方案。

解决方案

第一种方法假设您不关心跟踪大文件;因此不关心在GitHub上保留它的副本。在这种情况下，您需要回到过去以前的提交;在您添加大量违规文件之前进行提交。

您可以执行以下操作：

  git标签too_big＃一个保存点，以备日后使用时使用
 git log＃查找早期的COMMIT_ID 
 git reset --hard COMMIT_ID＃replace COMMIT_ID找到一个
 
＃看看现在情况如何
 git status 
  

如果在git status之后它不干净​​，也许你会对它感兴趣：

 ＃另外，这会把事情搞清楚
 git clean -df 
  

然后从这一点继续你的工作。

$ p $ g $ push $ master $＃假设你的分支是master
$ / code $

如果您需要恢复该巨型文件，该标记将为您提供一个参考点。当你尝试推送到GitHub时，它也会导致问题，并且因此只推送 master 而不是通用的（含糊的） git push （可能暗示 - 全部）。

---

或者，如果您必须将源代码管理应用于非常大的文件，您可以探索GitHub的LFS（大文件存储）git扩展。

https://git-lfs.github.com/

使用git子存储库（官方称为子模块）来处理大型文件可能是明智的做法。

https://git-scm.com/book/en/v2/Git-Tools-Submodules

I performed some load testing by using JMeter and then tried to checkin my project into git

by doing

git add .
git commit -m "message"
git push

I got an error message

Counting objects: 13, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (13/13), 50.13 MiB | 13.42 MiB/s, done.
Total 13 (delta 8), reused 0 (delta 0)
remote: error: GH001: Large files detected.
remote: error: File java_pid32554.hprof is 412.89 MB; this exceeds GitHub Enterprise's file size limit of 100.00 MB
To https://github.dev.myc.com/p/p.git
 ! [remote rejected] feature/branch -> feature/branch (pre-receive hook declined)
error: failed to push some refs to 'https://github.dev.myc.com/p/p.git'

To resolve the error I did the following

git rm java_pid32554.hprof
rm java_pid32554.hprof
added */*.hprof to .gitignore

Now I can see that the offending file is deleted from local file system. To be sure I also did a search

MacBook-Pro:p (feature/branch>)$ sudo find / -name java_pid32554.hprof
Password:
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory
MacBook-Pro:p (feature/branch>)$

So the file is indeed gone.

Now when I try

git push

it again gives the same error message.... even though the file is deleted.

I will not mark this question as a duplicate of this

My question presents a direct error message from git and the answer below is much more clear and direct. The other thread is cluttered with different types of solutions.

解决方案

This first approach assumes that you don't care about "tracking" the large file; and consequently don't care to keep a copy of it on GitHub. In that case, you'll need to "go back in time" to an earlier commit; to a commit before you added the large, offending file.

You can do the following to do that:

git tag too_big            # a "savepoint" just in case you care for it later
git log                    # find an earlier COMMIT_ID
git reset --hard COMMIT_ID # replace COMMIT_ID with the one found

# See how things are at this point
git status

If it's not clean after "git status", maybe you'd be interested in:

# Optionally, this will wipe things out
git clean -df

And then continuing your work from that point.

git push master     # assuming your branch is master

The tag will give you a point of reference if you ever need to restore that giant file. It will also cause problems when you try to push to GitHub, and thus, push only master as opposed to a general purpose (ambiguous) git push (possibly implying --all).

---

Alternatively, if you must apply "source code control" to the very large file for some reason, you can explore GitHub's LFS (Large File Storage) git extension.

https://git-lfs.github.com/

It might be wise to have a git sub-repository (officially known as submodule) for handling large files.

https://git-scm.com/book/en/v2/Git-Tools-Submodules

这篇关于检测到Git大文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！