目前我有

空的GitHub回购 SSH服务器恢复(main) 当地的回购

SSH服务器回购是最新的回购(生产站点),所以我从那里克隆了一个Git到本地。然后我尝试做一个git推送到GitHub。

一切都很好,但随后它说一些关于文件名。gz对GitHub太大。我不需要这个文件,所以我运行了几个Git命令从Git缓存中删除它,然后推回到SSH服务器。

我没有看到本地的大文件,但它仍然在SSH服务器上,即使git diff返回什么,git推送返回“一切都是最新的”-即使文件在本地回购中不可见,当我尝试推送到GitHub时,我仍然会得到错误

文件fpss.tar.gz是135.17 MB;这超过了GitHub的文件大小限制100mb

我遵循了“修复问题”列在GitHub帮助下的步骤,所以这不应该已经足够了吗?

当它不在本地或在git status/diff/push中列出时,文件如何仍然在以太中?


当前回答

我发现压缩比过滤分支更有用。我做了以下事情:

本地删除大文件。 提交本地删除。 软重置回X次提交(对我来说是3):git重置-软头~3。 然后重新提交所有的更改(AKA squash) git commit -m "合并提交的新消息" 推送压缩提交。

特殊情况(来自用户@lituo):如果上述情况不起作用,那么您可能会遇到这种情况。提交1包含大文件,由于大文件错误,提交1的推送失败。提交2删除了git rm——cached [file_name]的大文件,但提交2的推送仍然失败。您可以遵循上面相同的步骤,但不要使用HEAD~3,而是使用HEAD~2。

其他回答

所以我遇到了一个特殊的情况:我从gitlab克隆了一个存储库,其中包含一个大于100 mb的文件,但在git历史的某个时刻被删除了。后来,当我添加了一个新的github私人回购,并试图推到新的回购,我得到了臭名昭著的“文件太大”错误。到此为止,我不再能够访问原始的gitlab回购。然而,我仍然能够在我的机器上的LOCAL存储库上使用bfg-repo-cleaner推送到新的私有github回购:

$ cd ~
$ curl https://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar > bfg.jar
$ cd my-project
$ git gc
$ cd ../
$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-project
$ cd my-project
$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
$ git remote -v # confirm origin is the remote you want to push to
$ git push origin master

你可以使用

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file/dir>' HEAD

这将删除该文件历史记录中的所有内容。问题是该文件出现在历史记录中。

这个命令会改变提交的哈希值,这可能是一个真正的问题,特别是在共享存储库上。不应该在不了解后果的情况下进行。

编辑:git项目现在建议用户使用git filter-repo而不是git filter-branch。


使用git filter-repo

WARNING: git-filter-branch has a glut of gotchas generating mangled history
         rewrites.  Hit Ctrl-C before proceeding to abort, then use an
         alternative filtering tool such as 'git filter-repo'
         (https://github.com/newren/git-filter-repo/) instead.  See the
         filter-branch manual page for more details; to squelch this warning,
         set FILTER_BRANCH_SQUELCH_WARNING=1.

安装

[brew|pip3|...] install git-filter-repo

使用

要删除路径前缀为example/path/ To /something的任何文件,可以运行

git filter-repo --path example/path/to/something--invert-paths

要删除任何没有路径前缀example/path/ To /something的文件,可以运行

git filter-repo --path example/path/to/something

我尝试了以上所有的方法,但没有一个对我有效。

然后我想出了自己的解决办法。

First of all, you need a clean, up-to-date local repo. Delete all the large files. Now create a new folder OUTSIDE of your repo folder and use "Git create repository here" to make it a new Git repository, let's call it new_local_repo. This is it! All above methods said you have to clean the history..., well, I'm sick of that, let's create a new repo which has no history at all! Copy the files from your old, messed up local repo to the new, beautiful repo. Note that the green logo on the folder icon will disappear, this is promising because this is a new repo! Commit to the local branch and then push to remote new branch. Let's call it new_remote_branch. If you don't know how to push from a new local repo, Google it. Congrats! You have pushed your clean, up-to-date code to GitHub. If you don't need the remote master branch anymore, you can make your new_remote_branch as new master branch. If you don't know how to do it, Google it. Last step, it's time to delete the messed up old local repo. In the future you only use the new_local_repo.

我发现压缩比过滤分支更有用。我做了以下事情:

本地删除大文件。 提交本地删除。 软重置回X次提交(对我来说是3):git重置-软头~3。 然后重新提交所有的更改(AKA squash) git commit -m "合并提交的新消息" 推送压缩提交。

特殊情况(来自用户@lituo):如果上述情况不起作用,那么您可能会遇到这种情况。提交1包含大文件,由于大文件错误,提交1的推送失败。提交2删除了git rm——cached [file_name]的大文件,但提交2的推送仍然失败。您可以遵循上面相同的步骤,但不要使用HEAD~3,而是使用HEAD~2。

如果这个文件是你最近一次提交时添加的,而且你还没有推送到远程存储库,你可以删除这个文件并修改提交。

git rm --cached giant_file
    # Stage "giant_file" for removal with "git rm"
    # Leave it on disk with "--cached". if you want to remove it from disk
    # then ignore the "--cached" parameter
git commit --amend -CHEAD
    # Commit the current tree without the giant file using "git commit"
    # Amend the previous commit with your change "--amend" 
    # (simply making a new commit won't work, as you need
    # to remove the file from the unpushed history as well)
    # Use the log/authorship/timestamp of the last commit (the one we are
    # amending) with "-CHEAD", equivalent to --reuse-message=HEAD
git push
    # Push our rewritten, smaller commit with "git push"