отмена коммитов, которые привели к тому, что git push оказался неудачным - PullRequest
1 голос
/ 28 января 2012

Я случайно запустил commit в git-проекте с большим количеством файлов данных - их размер составляет несколько ГБ.

Тогда я попытался запустить push origin master. Он сжал все (в течение нескольких минут), а затем попытался загрузить его на сервер. Я пробовал несколько раз, но не повезло. Это бесплатный git-сервер, и поэтому пуш был неудачным (вероятно, размер проекта). Ошибка была:

Сжатие объектов: 100% (101/101), сделано. ошибка: сбой RPC; результат = 55, код HTTP = 0 фатален: удаленный конец неожиданно завис Написание объектов: 100% (101/101), 5,55 ГиБ | 10,39 МиБ / с, готово. Всего 101 (дельта 21), повторное использование 0 (дельта 0) смертельно: удаленный конец завис неожиданно фатально: ожидается нормально / ошибка, сказал помощник '0009 [ffefJMeysq / т |, Rj: V ޹{L<wܜ[G>@}"<}5 {> ZQW \ ~ Q'

Теперь я удалил поврежденный подкаталог data, используя git rm --cached -r data/, и (просто для безопасности) переместил его в другой каталог. Я повторно набрал git commit, а затем попытался сделать git push - но он все еще пытается переместить все эти данные!

Я бы откатил весь свой проект до более ранней версии, но, к сожалению, в это время я редактировал другие файлы.

Знаете ли вы, как я могу сказать git забыть, что каталог данных существовал? Большое спасибо!

Ответы [ 3 ]

2 голосов
/ 28 января 2012

При первом коммите вы добавили коммит с data/ в свой репозиторий. Делая git rm -r data/ и затем git commit, вы сделали второй коммит, который удаляет data/. git push должен загрузить оба коммита, так что это не помогло.

Кроме того, git rm --cached удаляет только данные из индекса. Я не думаю, что ваш второй коммит фактически удалил какие-либо файлы, но вы можете проверить это с помощью git log --stat.

Вам нужно переписать историю с помощью интерактивного перебазирования. Это не столько переписывание истории, сколько переписывание новой истории. Как страховой полис, начните с размещения тега, где master с git tag before_rebase. Тогда, если что-то пойдет не так, вы всегда можете вернуться к before_rebase и повторить попытку.

Вы говорите git, что хотите переписать историю, возвращаясь к origin/master с git rebase -i origin/master. Тогда вы получите редактор с чем-то вроде этого:

pick 064f41f Some change
pick 1ca69c3 Some other change
pick 1fa8921 Remove data/
pick 984alkj Huge amounts of data/
pick 82adlkj Bug fix

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

Как только вы закончите, используйте git log, чтобы убедиться, что изменения действительно пропали.

Теперь вы можете нажимать, и data/ полностью ушел из истории.

1 голос
/ 28 января 2012

Насколько я могу судить по вашему вопросу, вы удалили данные из хранилища, а затем зафиксировали удаление. Таким образом, данные все еще находятся в предыдущем коммите.

Чтобы избавиться от данных, вы можете использовать интерактивное обновление (git rebase -i). Например, предположим, что ваша история выглядит так:

  • ГОЛОВА
  • удалить большие файлы данных (никаких других изменений в этом коммите!)
  • изменения, которые вы хотите сохранить (1)
  • изменения, которые вы хотите сохранить (2)
  • добавить большие файлы данных (никаких других изменений в этом коммите!)
  • изменения, которые вы хотите сохранить (3)
  • ...

Тогда вы можете запустить git rebase -i HEAD~5 (5 - это количество коммитов, которые вы хотите интерактивно перебазировать). Это откроет редактор. В этом редакторе удалите коммит, в который вы добавили большие файлы данных, и удалите коммит, в котором вы удалили большие файлы данных. Сохраните файл и выйдите из редактора. Затем Git перестроит вашу ветку без этих двух коммитов, поэтому она будет выглядеть так:

  • ГОЛОВА
  • изменения, которые вы хотите сохранить (1)
  • изменения, которые вы хотите сохранить (2)
  • изменения, которые вы хотите сохранить (3)
  • ...

После этого git push больше не должен отправлять данные.

0 голосов
/ 28 января 2012

Если подкаталог с поврежденными данными все еще находится в папке, которую вы пытаетесь зафиксировать, git попытается зафиксировать ее независимо от того, удалили вы ее или нет. Вместо этого он просто увидит новый файл.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...