Не удается нажать на GitHub из-за большого файла, который я уже удалил

Ответ 1

Ты можешь использовать

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

Это удалит все в истории этого файла. Проблема в том, что файл присутствует в истории.

Эта команда изменяет хэши ваших коммитов, что может быть реальной проблемой, особенно в общих репозиториях. Это не должно выполняться без понимания последствий.

Ответ 2

Если файл был добавлен с вашей последней фиксацией, и вы не нажали на GitHub, вы можете удалить файл и внести изменения в commit, взятый здесь:

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

Ответ 3

У меня была аналогичная проблема, и я использовал этот шаг, чтобы удалить файл. Он отлично работал.

Затем я получил ошибку во втором файле, который мне нужно удалить: remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub file size limit of 100.00 MB remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub 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 error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: The remote end hung up unexpectedly

Это я исправил, непосредственно изменяя конфигурационный файл.git - postBuffer = 999999999

После этого толчок прошел!

Ответ 4

Я нашел давя более полезным, чем filter-branch. Я сделал следующее:

1. Локально удалять большие файлы.
2. Выполните локальные удаления.
3. Мягкий сброс назад X количество коммитов (для меня это было 3): git reset --soft HEAD~3.
4. Затем повторите все изменения вместе (AKA squash) git commit -m "New message for the combined commit"
5. Push squashed commit.

Особый случай (от пользователя @lituo): Если выше не работает, то у вас может быть этот случай. Commit 1 включил большой файл, а нажатие Commit 1 не удалось из-за большой ошибки файла. Commit 2 удалил большой файл с помощью git rm --cached [file_name] но нажатие Commit 2 еще не сработало. Вы можете выполнить те же шаги выше, но вместо использования HEAD~3 используйте HEAD~2.

Ответ 5

Почему GitHub отклоняет мое репо, даже после того, как я удалил большой файл?

Git хранит всю историю вашего проекта, поэтому даже если вы удалите файл из своего проекта, у Git repo все еще есть копия файла в истории, и если вы попытаетесь нажать на другой репозиторий (например, GitHub), то Git требует, чтобы удаленное репо имело ту же историю, что и ваш локальный репо (т.е. те же большие файлы в истории).

Как я могу заставить GitHub принять мое репо?

Вам необходимо очистить историю Git вашего проекта локально, удалив ненужные большие файлы из всей истории, а затем используйте только "очищенную" историю в будущем. Идентификаторы Git для блокированных изменений будут изменены.

Как очистить большие файлы из моего репозитория Git?

Лучший инструмент для очистки нежелательных больших файлов из истории Git - это BFG Repo-Cleaner - это более простая и быстрая альтернатива git-filter-branch специально разработанная для удаления нежелательных файлов из истории Git.

Внимательно следуйте инструкциям по использованию, основная часть:

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

Любые файлы размером более 100 МБ (которые не входят в вашу последнюю фиксацию) будут удалены из истории вашего репозитория Git. Затем вы можете использовать git gc для удаления мертвых данных:

$ git gc --prune=now --aggressive

BFG обычно не менее чем на 10-50 раз быстрее, чем работает git-filter-branch, и, как правило, намного проще в использовании.

Полное раскрытие: я являюсь автором BFG Repo-Cleaner.

Ответ 6

У меня такая же проблема, и ни один из ответов не работает для меня. Я решил следующие шаги:

1. Найти, какие фиксаторы содержат большой файл

git log --all -- 'large_file`

Нижняя фиксация - это самая старая фиксация в списке результатов.

2. Найдите тот, который находится перед самым старым.

git log

Предположим, что вы получили:

commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

3. Git rebase

git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

Советы:

• Элемент списка
• Я просто выбираю drop для коммитов, содержащих большой файл.
• Вы можете встретить конфликты во время переустановки, исправить их и использовать git rebase --continue для продолжения, пока не закончите.
• Если во время rebase что-то пошло не так, используйте git rebase --abort, чтобы отменить его.