У меня был репозиторий с плохими коммитами (D, E и F для этого примера).
ABCDEF мастер и происхождение / мастер
Я изменил местный репозиторий специально с git reset --hard
. Я взял ветку до сброса, так что теперь у меня есть репозиторий, который выглядит так:
A-B-C master
\ D-E-F old_master
A-B-C-D-E-F origin/master
Теперь мне нужны были некоторые части этих плохих коммитов, поэтому я выбрал нужные биты и сделал несколько новых коммитов, так что теперь у меня есть следующее:
A-B-C-G-H master
\ D-E-F old_master
Теперь я хочу перенести это положение на удаленное репо. Тем не менее, когда я пытаюсь сделать git push
Git вежливо, я отмахиваюсь:
$ git push origin +master:master --force
Total 0 (delta 0), reused 0 (delta 0)
error: denying non-fast forward refs/heads/master (you should pull first)
To git@git.example.com:myrepo.git
! [remote rejected] master -> master (non-fast forward)
error: failed to push some refs to 'git@git.example.com:myrepo.git'
Как заставить удаленное репо принять текущее состояние локального репо?
git push -force
более осторожно .Ответы:
Если принудительное нажатие не помогает ("
git push --force origin
" или "git push --force origin master
" должно быть достаточно), это может означать, что удаленный сервер отказывается от push-уведомлений без ускоренной пересылки либо через переменную конфигурации receive.denyNonFastForwards (см. Описание на странице конфигурации git config ), либо через хук обновления / предварительного получения.В более старом Git вы можете обойти это ограничение, удалив «
git push origin :master
» (см. «:» Перед именем ветви), а затем заново создав «git push origin master
» данную ветку.Если вы не можете изменить это, то единственным решением было бы вместо переписывания истории создать коммит, возвращающий изменения в DEF :
источник
get revert HEAD~N
помог.N
это количество коммитов. Например, если мне понадобится предыдущий коммит, я буду использоватьgit revert HEAD~1
В дополнение к ответу Якуба, если у вас есть доступ к удаленному git-серверу в ssh, вы можете зайти в удаленный каталог git и установить:
Затем вернитесь в локальный репозиторий и попробуйте снова выполнить коммит
--force
:И, наконец, вернуть настройки сервера в исходное защищенное состояние:
источник
vi
приведены в этом сообщении SO: stackoverflow.com/a/43721579/2073804Вместо того, чтобы исправлять вашу «главную» ветку, проще заменить ее на «желаемый мастер», переименовав ветви. См. Https://stackoverflow.com/a/2862606/2321594 . Таким образом, вы даже не оставите никаких следов нескольких обращенных журналов.
источник
Весь бизнес, связанный с перезагрузкой, выглядел далеко не таким сложным для меня.
Так что я сделал что-то вроде того, чтобы моя папка src была в том состоянии, в котором я был несколько коммитов назад.
Таким образом, состояние дел в src сохраняется в файле tar, и git вынужден принимать это состояние без особых усилий, в основном каталог src заменяется состоянием, которое было несколько коммитов назад.
источник
Для пользователей GitHub это работает для меня:
git reset --hard <full_hash_of_commit_to_reset_to>
git push --force
Это «исправит» историю веток на вашем локальном компьютере и на сервере GitHub, но любой, кто синхронизировал эту ветку с сервером после плохой фиксации, будет иметь историю на своей локальной машине. Если у них есть разрешение на прямую передачу в ветку, тогда эти коммиты будут отображаться обратно при синхронизации.
Все остальное, что нужно сделать, - это
git reset
команда сверху, чтобы «исправить» ветку на их локальной машине. Конечно, они должны быть осторожны с любыми локальными коммитами, сделанными в этой ветке после целевого хэша. Вишня выбирает / резервирует и повторно применяет их по мере необходимости, но если вы находитесь в защищенной ветке, то число людей, которые могут принять непосредственное участие в ней, вероятно, ограниченоисточник