Удалите PR Merge, затем Merge Later [duplicate]
#parent { position : relative; height: 0; overflow: hidden; padding-bottom: 56.25% /* images with aspect ratio: 16:9 */ } img { height: auto!important; width: auto!important; min-height: 100%; min-width: 100%; position: absolute; display: block; /* */ top: -9999px; bottom: -9999px; left: -9999px; right: -9999px; margin: auto; }Я не помню, где я увидел описанный выше метод центрирования, используя отрицательные верхние, правые, нижние, левые значения. Для меня эта техника лучше всего в большинстве ситуаций.
Когда я использую комбинацию сверху, изображение ведет себя как фоновое изображение со следующими настройками:
background-position: 50% 50%; background-repeat: no-repeat; background-size: cover;Подробнее о первом примере можно найти здесь: Поддерживать соотношение сторон div с CSS
6 ответов
В этой проблеме есть лучший ответ , хотя я мог бы просто сломать это шаг за шагом.
Вам нужно будет выбрать и проверить последние изменения восходящего потока, например:
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Теперь вы хотите вернуть весь запрос на растяжение с возможностью его дальнейшего отказа. Для этого вам нужно будет взять идентификатор merge commit .
В приведенном выше примере слияние слияния является верхней, где говорит «Объединенный запрос на тягу № 123 ...» .
Сделайте это, чтобы вернуть оба изменения ( «Добавить панель» и " Добавьте foo "), и вы получите в одном компе, возвращающем весь запрос на pull, который вы можете позже удалить и сохранить историю изменений в чистоте:
git revert -m 1 b76a5f1f5d3b323679e466a1a1d5f93c8828b269
Чтобы отменить запрос на github pull с фиксацией на протяжении всего, что вы не хотите удалять, вам необходимо запустить:
git reset --hard --merge <commit hash>
, когда хеш фиксации является фиксацией ПРИОР для слияния запроса на вытягивание. Это удалит все коммиты из запроса на растяжение, не оказывая влияния на какие-либо фиксации в истории.
Хороший способ найти это - перейти к теперь закрытому запросу на растяжение и найти это поле:
[/g1] Pull Request Image
После запуска git reset запустите a:
git push origin --force <branch name>
Это должно вернуть ветку назад перед запросом на извлечение БЕЗ воздействия на любые коммиты в ветке, перечеркнутые в историю фиксации, между фиксациями из запроса на pull.
EDIT:
Если вы чтобы щелкнуть кнопку возврата на запрос pull, это создает дополнительную фиксацию на ветке. Он НЕ РАСПРОСТРАНЯЕТСЯ или НЕ РАЗРЕШАЕТ. Это означает, что если вы нажмете кнопку возврата, вы не сможете открыть новый запрос на pull для повторного добавления всего этого кода.
-
1Отличный способ получить вещи выпрямлены без необходимости сумасшедшего возвращения или сбора вишни – Cumulo Nimbus 18 July 2017 в 18:59
-
2Благодаря! Это было то, что я планировал делать, но это было бы около 200 попыток вычеркнуть вишню. – FluffySamurai 18 July 2017 в 19:14
Посмотрите на свой график фиксации (с помощью gitk или аналогичной программы). Вы увидите коммиты из запроса на вытягивание, и вы увидите свои собственные фиксации и фиксацию слияния (если бы это было не быстрое слияние). Вам просто нужно найти последние свои собственные коммиты перед слиянием и сбросить ветвь на эту фиксацию.
(Если у вас есть рефлок филиала, должно быть еще проще найти фиксацию до слияния .)
(Редактировать после получения дополнительной информации в комментариях:)
[/g3]
Я предполагаю, что последний (самый правый) commit был вашим неправильным слиянием по запросу pull , который объединил синюю линию, показанную здесь. Ваша последняя хорошая фиксация будет той, что была раньше на черной линии, здесь отмечена красным:
[/g4]
Сбросить к этому [, g12]
Это означает, что в вашей локальной рабочей копии сделайте это (после того, как вы убедитесь, что у вас больше нет неподтвержденных вещей, например, git stash):
git checkout master
git reset --hard 7a62674ba3df0853c63539175197a16122a739ef
gitk
Теперь подтвердите, что вы действительно находитесь на коммите, который я там отмечен, и вы не увидите ни одного из вытащенных материалов в своей родословной.
git push -f origin master
(если ваш пульт github называется origin - иначе измените имя).
Теперь все должно выглядеть прямо на github. Коммиты будут по-прежнему находиться в вашем хранилище, но не достижимы ни одной веткой, поэтому они не должны навредить. (И они будут все еще в репозитории Роджер Паладина, конечно.)
(Может быть, Github-специфический способ только для Интернета сделать то же самое, но я не слишком знаком с Github и его тягой
Обратите внимание, что если кто-то еще, возможно, потянул вашего хозяина с неправильной фиксацией, у них возникнет такая же проблема, как у вас в настоящее время, и она не может действительно помочь. перед тем, как вернуться к новой версии мастера.
Если возможно, что это произошло или вы просто хотите избежать каких-либо проблем, используйте команду git revert вместо git reset, чтобы вернуть изменения с помощью new commit, вместо того, чтобы вернуться к более старому. (Некоторые люди думают, что вы никогда не должны выполнять сброс с опубликованными ветвями.) См. Другие ответы на этот вопрос о том, как это сделать.
В будущем:
Если вы хотите только некоторые из фиксации ветки Роджера Паладина, используйте cherry-pick вместо merge. Или свяжитесь с RogerPaladin, чтобы переместить их в отдельную ветку и отправить новый запрос на pull.
-
1Но у нас есть тонна коммитов между слиянием и его первым фиксацией. Так что, как будто мы совершаем слияние, наши собственные совершают, а затем совершают другие действия. Похоже, что он слился с действительно старыми делами. – Will 26 June 2011 в 02:53
-
2Да, теперь он выглядит правильно (кроме странного слияния в себя ), но это может быть сбой в программном обеспечении сетевого графика). :-) Я рад, что смогу помочь. – Paŭlo Ebermann 26 June 2011 в 04:19
-
3Я думаю, что это может быть проблематично, если кто-то потянул плохие коммиты, и они позже отправили запрос на тяну, содержащий те же плохие коммиты, таким образом, они прокрались, но в репо. Не было бы безопаснее создавать новую фиксацию, которая отменяет плохие коммиты? Таким образом, если плохие коммиты были вытащены на другие ветви / вилки, они будут эффективно удалены другим притяжением к этой другой ветке / вилке? Я не утверждаю это как факт, это то, что я думаю может быть правдой, находясь в том же положении, что и OP, и потратил час или около того, рассматривая мои варианты. – Myles McDonnell 17 December 2012 в 16:40
-
4@ Будем предлагать не принимать этот ответ. Это хорошо для кода, который еще не был нажат (в этом случае этот является более актуальным вопросом SO, но для кода, который является общедоступным, выполняет команду git, которая перезаписывает историю (в этом case,
reset --hardи силовой толчок - очень плохая практика). Ответ от @errordeveloper ниже показывает способ сделать это без какой-либо перезаписи истории или принудительного нажатия. – asmeurer 15 February 2016 в 21:29 -
5
Я использую это место все время, спасибо.
Я искал, как отменить запрос на растяжение и попал сюда.
Я собирался только git reset --hard до «давным-давно» и проделайте быстрый переход туда, где я был, прежде чем делать запрос на тягу.
Кроме того, что я смотрю здесь, я также спросил своего коллегу, что он будет делать, и у него был типичный Хороший ответ: используя пример вывода в первом ответе выше:
git reset --hard 9271e6e
Как и в большинстве случаев в Git, если вы делаете это не так, вы, вероятно, ошибаетесь.
Если притяжение было последним, что он сделал, то
git reset --hard HEAD~1
-
1будьте осторожны, следуя этой инструкции, она фактически вернула мне 2 шага, а не одну. – szeitlin 13 January 2016 в 00:57
-
2@szeitlin Как это могло случиться, что вам потребовалось 2 шага, а не один? Я знаю, что этот комментарий был оставлен 4+ года назад, но мне любопытно, знает ли кто-нибудь ответ, как это может произойти. Это очень важно для меня. Благодарю. – Haradzieniec 3 June 2016 в 15:33
-
3Я не помню сейчас, но я предполагаю, что это может произойти, если я сделал новую фиксацию, когда попытался сбросить настройки? Я бы просто протестировал его с помощью фиктивного репо, если вы беспокоитесь об этом. – szeitlin 6 June 2016 в 16:01
Начиная с 24 июня 2014 года, вы можете попробовать с легкостью отключить PR (см. «« Возврат запроса на растяжение ») с помощью:
вы можете легко вернуть запрос на перенос на GitHub, щелкнув Revert:
[/g2]
Вам будет предложено создать новый запрос на растяжение с отмененными изменениями:
[/g3]
Остается проверить, хотя если этот возврат использует
-mили нет (для повторного слияния тоже)
-
1Я попробовал это, и он создал новую ветку вместо того, чтобы отменить PR на master? – Tsar 15 March 2017 в 11:31
-
2Странный. Не могли бы вы задать новый вопрос, чтобы проиллюстрировать это поведение? – VonC 15 March 2017 в 11:35
git checkout upstream/master -b revert/john/foo_and_bar? что он делает точно? – Magne 22 August 2014 в 16:54