Кто-то принял запрос на перенос, которого у них не было. Теперь у нас есть куча сломанного кода, объединенного. Как вы отменили запрос на pull? Я просто собирался вернуть изменения в commit непосредственно перед слиянием, но я заметил, что он объединился в кучу коммитов. Итак, теперь есть все эти коммиты от этого человека за несколько дней до слияния. Как вы отменили это?
Ответ 1
В этой проблеме есть лучший ответ, хотя я мог бы просто сломать это шаг за шагом.
Вам нужно будет выбрать и проверить последние изменения восходящего потока, например:
git fetch upstream
git checkout upstream/master -b revert/john/foo_and_bar
Взглянув на журнал фиксации, вы должны найти что-то похожее на это:
commit b76a5f1f5d3b323679e466a1a1d5f93c8828b269 Merge: 9271e6e a507888 Author: Tim Tom <tim@tom.com> Date: Mon Apr 29 06:12:38 2013 -0700 Merge pull request #123 from john/foo_and_bar Add foo and bar commit a507888e9fcc9e08b658c0b25414d1aeb1eef45e Author: John Doe <john@doe.com> Date: Mon Apr 29 12:13:29 2013 +0000 Add bar commit 470ee0f407198057d5cb1d6427bb8371eab6157e Author: John Doe <john@doe.com> Date: Mon Apr 29 10:29:10 2013 +0000 Add foo
Теперь вы хотите вернуть весь запрос на тягу с возможностью позже отменить его. Для этого вам нужно будет взять идентификатор фиксации слияния.
В приведенном выше примере объединение слияния является верхним, где указано "Объединенный запрос на вытягивание № 123...".
Сделайте это, чтобы вернуть оба изменения ( "Добавить панель" и "Добавить foo" ), и вы получите в одном компе, возвращающем весь запрос на растяжение, который вы можете позже удалить и сохранить историю изменений в чистоте:
git revert -m 1 b76a5f1f5d3b323679e466a1a1d5f93c8828b269
Ответ 2
Посмотрите на свой график фиксации (с помощью gitk или аналогичной программы). Вы увидите коммиты из запроса на вытягивание, и вы увидите свои собственные фиксации и фиксацию слияния (если бы это было не быстрое слияние). Вам просто нужно найти последние свои собственные коммиты перед слиянием и reset ветвь для этой фиксации.
(Если у вас есть ветка reflog, должно быть еще проще найти фиксацию до слияния.)
(Изменить после получения дополнительной информации в комментариях:)
Хорошо, давайте посмотрим на график:
Я предполагаю, что последний (самый правый) фиксатор был вашим неправильным слиянием по запросу pull, который объединил синюю линию, показанную здесь. Ваша последняя хорошая фиксация будет той, что была на черной линии, здесь отмечена красным цветом:
Reset к этой фиксации, и все должно быть хорошо.
Это означает, что в вашей локальной рабочей копии сделайте это (после того, как вы убедитесь, что у вас больше нет неподтвержденных вещей, например, git stash):
git checkout master
git reset --hard 7a62674ba3df0853c63539175197a16122a739ef
gitk
Теперь подтвердите, что вы действительно находитесь на фиксации, который я там помечен, и вы не увидите ни одного из вытащенных материалов в своей родословной.
git push -f origin master
(если ваш удаленный github называется origin - иначе измените имя).
Теперь все должно выглядеть правильно на github. Коммиты будут по-прежнему находиться в вашем хранилище, но не достижимы ни одной веткой, поэтому они не должны навредить. (И они, конечно, будут все еще в репозитории RogerPaladin.)
(Возможно, существует только один способ Github для работы с одним и тем же, но я не слишком хорошо знаком с Github и системой управления запросами на pull.)
Обратите внимание, что, если кто-то еще, возможно, потянул вашего хозяина с неправильной фиксацией, у них возникнет такая же проблема, как у вас в настоящее время, и она не может действительно помочь. перед сбросом на новую версию мастера.
Если возможно, что это произошло, или вы просто хотите избежать каких-либо проблем, используйте команду git revert вместо git reset, чтобы отменить изменения с помощью новой фиксации вместо того, чтобы вернуться к более старой. (Некоторые люди думают, что вы никогда не должны делать reset с опубликованными ветвями.) См. Другие ответы на этот вопрос о том, как это сделать.
В будущем:
Если вы хотите использовать только некоторые из записей ветки RogerPaladin, используйте cherry-pick вместо merge. Или свяжитесь с RogerPaladin, чтобы переместить их в отдельную ветку и отправить новый запрос на pull.
Ответ 3
Если тянуть было последним, что он сделал, то
git reset --hard HEAD~1
Ответ 4
Начиная с 24 июня 2014 года, вы можете попробовать с легкостью отменить PR (см. "Возврат запроса на перенос") с помощью:
Представляем кнопку "Отменить"
вы можете легко вернуть запрос на перенос на GitHub, нажав кнопку "Отменить":
Вам будет предложено создать новый запрос на перенос с отмененными изменениями:
Осталось проверить, хотя если это возвращает, используется -m или нет (для повторного слияния тоже)
Ответ 5
Чтобы отменить запрос на github pull с фиксацией на протяжении всего, что вы не хотите удалять, вам нужно запустить:
git reset --hard --merge <commit hash>
когда хеш фиксации является фиксацией PRIOR для слияния запроса на pull. Это приведет к удалению всех коммитов из запроса на растяжение без влияния на какие-либо фиксации в истории.
Хороший способ найти это - перейти к теперь закрытому запросу на растяжение и найти это поле:
После запуска git reset запустите a:
git push origin --force <branch name>
Это должно вернуть ветку назад перед запросом на вытягивание БЕЗ воздействия на какие-либо коммиты в ветке, запертой в историю фиксации, между фиксацией по запросу pull.
EDIT:
Если вы нажмете кнопку возврата на запрос тянуть, это создаст дополнительную фиксацию на ветке. Он НЕ РАСПРОСТРАНЯЕТСЯ или НЕ РАЗРЕШАЕТ. Это означает, что если вы нажмете кнопку возврата, вы не сможете открыть новый запрос на pull для повторного добавления всего этого кода.
Ответ 6
Я использую это место все время, спасибо.
Я искал, как отменить запрос на растяжение и попасть сюда.
Я собирался просто git reset --hard в "давно" и
сделайте быстрый переход назад туда, где я был, прежде чем делать запрос на тяну.
Кроме того, чтобы посмотреть здесь, я также спросил своего коллегу, что он будет делать, и у него был типично хороший ответ: используя пример, выводимый в первый ответ выше:
git reset --hard 9271e6e
Как и в большинстве случаев в Git, если вы делаете это не так просто, вы, вероятно, ошибаетесь.