web-dev-qa-db-ja.com

既に削除した大きなファイルのためにGitHubにプッシュできません

現在私は持っています

  1. 空のGitHubリポジトリ
  2. SSHサーバーリポジトリ(メイン)
  3. ローカルレポ

SSHサーバーリポジトリは最新のリポジトリ(運用サイト)だったので、そこからローカルにGitクローンを作成しました。その後、GitHubに対してgit Pushを実行しようとしました。

すべてうまくいきましたが、GitHubにはfilename.gzが大きすぎるということを言っていました。このファイルは必要なかったので、Gitコマンドを実行してGitキャッシュから削除し、SSHサーバーにプッシュバックしました。

大きなファイルがローカルに表示されませんが、git diffが何も返さず、Git Pushが「すべてが最新」を返しますが、SSHサーバー上にあります。 GitHubに私はまだそれについてのエラーを取得します

リモート:エラー:ファイルfpss.tar.gzは135.17 MBです。これは、GitHubのファイルサイズ制限である100 MBを超えています

「問題の修正」の下の手順に従いました GitHubヘルプにリストされています だから、それで十分ではないでしょうか?

ファイルがローカルでないか、git status/diff/pushにリストされていない場合、ファイルはどのようにエーテルに残っていますか?

186
SuperDistros

使用できます

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

これにより、そのファイルの履歴内のすべてが削除されます。問題は、ファイルが履歴に存在することです。

このコマンドは、コミットのハッシュを変更します。これは、特に共有リポジトリで実際の問題になる可能性があります。結果を理解せずに実行しないでください。

365
MacGyver

ファイルが最新のコミットで追加され、かつGitHubにプッシュされていない場合、ファイルを削除してコミットを修正できます。 here から取得:

git rm --cached giant_file
    # Stage our giant file for removal, but leave it on disk
git commit --amend -CHEAD
    # Amend the previous commit with your change
    # Simply making a new commit won't work, as you need
    # to remove the file from the unpushed history as well
git Push
    # Push our rewritten, smaller commit
34
BlueMoon93

squashingfilter-branchよりも便利だと思いました。私は次のことをしました:

  1. 大きなファイルをローカルで削除します。
  2. ローカル削除をコミットします。
  3. X件のコミットのソフトリセットバック(私にとっては3):git reset --soft HEAD~3
  4. 次に、すべての変更をまとめて再コミットします(別名スカッシュ)git commit -m "New message for the combined commit"
  5. 押しつぶされたコミット。

特別な場合(ユーザー@lituoから):上記が機能しない場合は、この場合。コミット1には大きなファイルが含まれ、コミット1のプッシュは大きなファイルエラーのために失敗しました。コミット2はgit rm --cached [file_name]によって大きなファイルを削除しましたが、コミット2のプッシュはまだ失敗しました。上記と同じ手順を実行できますが、HEAD~3を使用する代わりに、HEAD~2を使用します。

同様の問題があり、上記の ステップ を使用してファイルを削除しました。完璧に機能しました。

次に、削除する必要がある2番目のファイルでエラーが発生しました:remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub's file size limit of 100.00 MB

私は同じステップを試みましたが、エラーが発生しました:"A previous backup already exists in <path/filename>"

このウェブサイトの調査から コマンドを使用しました:git filter-branch --force --index-filter "git rm --cached --ignore-unmatch <path/filename>" --Prune-empty --tag-name-filter cat -- --all

うまく機能し、大きなファイルは削除されました。

信じられないほど、プッシュはまだ別のエラーで失敗しました:error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: The remote end hung up unexpectedly

これは、.git構成ファイルを直接変更することで修正しました-postBuffer = 999999999

その後、プッシュが通過しました!

13
Andre Odendaal

大きなファイルを削除した後でも、GitHubがレポジトリを拒否するのはなぜですか?

Gitはプロジェクトの完全な履歴を保存するため、プロジェクトからファイルを「削除」しても、Gitリポジトリにはファイルのコピーがまだ履歴にあり、別のリポジトリ(でホストされているリポジトリなど)にプッシュしようとするとGitHub)次にGitrequiresリモートリポジトリには、ローカルリポジトリと同じ履歴があります(つまり、履歴内の同じ大きなファイル)。

GitHubでレポジトリを受け入れるにはどうすればよいですか?

プロジェクトのGit履歴をローカルでクリーンアップし、すべての履歴から不要な大きなファイルを削除してから、今後は「クリーンアップされた」履歴のみを使用する必要があります。影響を受けるコミットのGitコミットIDが変更されます。

Gitリポジトリから大きなファイルを削除するにはどうすればよいですか?

Gitの履歴から不要な大きなファイルを削除するための最適なツールは BFG Repo-Cleaner です。これは、Gitの履歴から不要なファイルを削除するために特別に設計されたgit-filter-branchのよりシンプルで高速な代替手段です。

使用方法 を注意深く守ってください。コア部分はこれだけです:

$ Java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git

サイズが100MBを超えるファイル(latestコミットにないファイル)は、Gitリポジトリの履歴から削除されます。その後、git gcを使用して、デッドデータを削除できます。

$ git gc --Prune=now --aggressive

BFGは通常、少なくとも 10-50xgit-filter-branchを実行するよりも高速で、一般的にははるかに使いやすいです。

完全開示:私はBFG Repo-Cleanerの著者です。

9
Roberto Tyley

あなたが助けを求める前にあなたがすでにあなたのレポをいじくり回しているなら、ここに私が非常に役立つと思う何かがあります。最初のタイプ:

git status

この後、次の行に沿って何かが表示されます

On branch master
Your branch is ahead of 'Origin/master' by 2 commits.
  (use "git Push" to publish your local commits)

nothing to commit, working tree clean

重要な部分は「2コミット」です!ここから、入力してください:

git reset HEAD~<HOWEVER MANY COMMITS YOU WERE BEHIND>

したがって、上記の例では、次のように入力します。

git reset HEAD~2

入力後、「git status」に次のように表示されるはずです。

On branch master
Your branch is up to date with 'Origin/master'.

nothing to commit, working tree clean

そこから、大きなファイルを削除できます(まだ削除していない場合)。作業を失うことなく、すべてを再コミットできるはずです。
これは超豪華な返信ではないことは知っていますが、お役に立てば幸いです!

7
Saber Nomen

私は同じ問題を抱えていたが、答えはどれも役に立たなかった。次の手順で解決しました。

1.大きなファイルが含まれるコミットを見つける

git log --all -- 'large_file`

一番下のコミットは、結果リストの最も古いコミットです。

2.最も古いものの直前のものを見つけます。

git log

あなたが得たと仮定します:

commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

3. Gitリベース

git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

ヒント

  1. リストアイテム
  2. コミットには大きなファイルが含まれているため、単にdropを選択します。
  3. リベース中に競合が発生し、それらを修正し、git rebase --continueを使用して、完了するまで続行することができます。
  4. リベース中に何か問題が発生した場合は、git rebase --abortを使用してキャンセルします。
2
William Hu