Запрос на вытягивание GitHub, показывающий коммиты, которые уже находятся в целевой ветке


138

Я пытаюсь просмотреть запрос на перенос на GitHub в ветку, которая не является ведущей. Целевая ветка находилась за master, и запрос на вытягивание показал коммиты от master, поэтому я объединил master и отправил его на GitHub, но коммиты и различия для них все еще появляются в запросе на вытягивание после обновления. Я дважды проверил, что ветка на GitHub имеет коммиты от мастера. Почему они все еще появляются в запросе на перенос?

Я также проверил запрос на перенос локально, и он показывает только неслитые коммиты.


Влияет ли это на поведение слияния PR?
Натан Хинчи

Нет, просто разница на Github.
лобати

Кто-нибудь знает, страдает ли собственный Gitlab таким же поведением?
Джефф Веллинг,

3
Я предлагаю всем нам связаться с GitHub, чтобы выразить нашу заинтересованность в изменении этого поведения ( support.github.com/contact ). Если они не получат от нас известий, они не узнают, насколько это важно, и так будет всегда.
steinybot

Ответы:


108

Похоже, что Pull Request не отслеживает изменения в целевой ветке (я связался со службой поддержки GitHub и 18 ноября 2014 года получил ответ, в котором говорилось, что это сделано намеренно).

Однако вы можете заставить его показать вам обновленные изменения, выполнив следующие действия:

http://githuburl/org/repo/compare/targetbranch...currentbranch

Заменить githuburl, org, repo, targetbranch, и currentbranchв случае необходимости.

Или, как указал Хексспрайт в своем ответе, вы также можете принудительно обновить его, щелкнув EditPR и временно изменив базу на другую ветку и обратно. Это вызывает предупреждение:

Вы уверены, что хотите сменить базу?

Некоторые коммиты из старой базовой ветки могут быть удалены с временной шкалы, а старые комментарии могут стать устаревшими.

И оставим в журнале PR две записи :

введите описание изображения здесь


4
Да, некоторое время назад я обратился в службу поддержки и получил такой же ответ. Они не оптимизируются для этой ситуации. Это немного расстраивает. Наш способ обойти это - просто перебазировать и принудительно подтолкнуть вверх или закрыть тягу и создать новую.
lobati

4
Этот ответ не решает проблему, а просто позволяет пользователю увидеть истинную разницу.
FearlessFuture

4
Возник вопрос: «Почему они все еще появляются в запросах на вытягивание?». Он отвечает на этот вопрос.
Adam Millerchip

3
Посмотрите мой комментарий, чтобы найти хорошее решение. Вы можете просто использовать кнопку редактирования PR, чтобы переключиться на другую ветвь, а затем вернуться к исходной базовой ветке, и она пересчитает разницу.
hexsprite

11
Есть ли запрос дорогой github, чтобы это изменить?
vossad01

91

Вот хорошее решение. Используйте Editкнопку при просмотре PR в GitHub, чтобы изменить базовую ветку на что-то другое, кроме master. Затем переключите его обратно на, masterи теперь он будет правильно отображать только изменения из самых последних коммитов.


4
Я удивлен, что все больше людей не признают это решение. Я подозреваю, что исходный запрос на перенос с устареванием будет в порядке, но мне не понравилось, что GitHub показывает все устаревшие файлы, поэтому я использовал его, и он сохраняет комментарий и показывает только фактические изменения, которые будут объединены , Спасибо!
таранаки

2
У меня не получилось.
Шашанк,

Черт возьми, это работает!
Анураг Хазра,

Три года спустя, и это все еще отличное решение. И посмотрите, кто-то только что прокомментировал несколько часов назад ^^^
Рикардо Сапорта

Это, похоже, не работает для меня, он просто добавляет информацию о том, что я изменил базовую ветку на что-то еще, а затем вернулся к мастеру. cfr: github.com/europeana/search/pull/30
Calvin

34

Подводя итог, GitHub не обновляет историю коммитов автоматически в запросах на вытягивание. Самые простые решения:

Решение 1. Rebase

Предположим, вы хотите слиться masterс feature-01:

git fetch origin
git checkout feature-01
git rebase origin/master
git push --force

Если вы работаете над вилкой, вам может потребоваться заменить ее originна upstream. См. Как мне обновить разветвленный репозиторий GitHub? чтобы узнать больше об отслеживании удаленных веток исходного репозитория.

Решение 2. Создайте новый запрос на перенос

Предположим, вы хотите объединить вступление masterиз feature-01:

git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased

Теперь откройте запрос на feature-01-rebasedвключение и закройте запрос для feature-01.


4
Перебазирование изменяет хэши фиксации, так что не приведет ли он к уничтожению существующих комментариев обзора?
haridsv

@haridsv Наверное, да.
Mateusz Piotrowski

На что нужно обратить внимание при выполнении push -force?
Пол Бендевис

1
@haridsv это не мой опыт. Я часто перебазирую середину обзора, и комментарии не теряются. Хотя я потерять историю изменений в PR
Joel

@JoelBerkeley Я на самом деле испытал пару обзоров, в которых автор перебазировал и заметил, что комментарии в порядке. Однако мы теряем возможность рецензирования постепенно, а для больших рецензий это огромный штраф для рецензентов. Теперь у нас есть несколько рекомендаций для наших PR, и одно из них - никогда не перебазировать после открытия обзора (если только кто-то не уверен, что никто еще не начал рецензирование). Слияние - это нормально, но мы рекомендуем не смешивать изменение слияния с любыми другими изменениями, кроме разрешения конфликтов.
haridsv

17

Вам необходимо добавить в свой ~/.gitconfigфайл следующее:

[rebase]
    autosquash = true

Это автоматически приведет к тому же, что показывает этот ответ .

Я получил это отсюда .


2
блин, я случайно нажал на голосование. этот ответ мне помог. позвольте мне изменить это, пожалуйста.
Гектор

@hosein Давай. Вы должны это сделать сейчас.
Mateusz Piotrowski

1
Я думаю, что это должен быть принятый ответ или включенный в принятый ответ. Это дает результат, который я искал!
Рональд Рей

1
@RonaldRey git rebasing не является универсальным решением, поскольку предполагает редактирование истории. Если все работают над частными форками, которые никогда не клонируются другими, то это нормально, но как только кто-то клонирует ваш репозиторий, а вы затем редактируете историю, у вас получается другая история.
Адам Миллерчип 03

14

Для всех, кто сталкивался с этим и был сбит с толку поведением GitHub Pull Request, основная причина заключается в том, что PR - это различие кончика исходной ветки с общим предком исходной ветки и целевой ветки. Поэтому он покажет все изменения в исходной ветке до общего предка и не будет принимать во внимание какие-либо изменения, которые могли произойти в целевой ветке.

Дополнительная информация доступна здесь: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

Различия на основе общих предков кажутся опасными. Я бы хотел, чтобы у GitHub была возможность сделать более стандартный PR на основе трехстороннего слияния.


1
Причина, о которой вы упомянули, кажется правильной, но я смущен, потому что обычно всякий раз, когда мастер обновляется, я объединяю изменения в свою ветку ... git checkout my-branch -> git merge master . Запрос на вытягивание обновляется немедленно. Обновляется ли общий предок?
G.One

2
Такое поведение, кажется, происходит при выполнении перебазирования вместо слияния
G.One

1
@ G.One, очень поздний ответ, но да - если вы выполните слияние из этой основной ветки в исходную ветку, вы по определению обновите общего предка. Это фиксация мастера, из которой вы слились.
Дэвид К. Хесс

13

Один из способов исправить это - git rebase targetbranchв том пиаре. Затем git push --force targetbranchGithub покажет правильные коммиты и diff. Будьте осторожны с этим, если не знаете, что делаете. Возможно, сначала проверьте тестовую ветку, чтобы выполнить перебазирование, а затем git diff targetbranchубедиться, что это все еще то, что вы хотите.


10

Это происходит с GitHub, когда вы объединяете коммиты из целевой ветки.

Я использовал сквош и слияние с Github в качестве стратегии слияния по умолчанию, включая слияния из целевой ветки. Это вводит новую фиксацию, и GitHub не распознает, что эта сжатая фиксация такая же, как и уже существующие в мастере (но с другими хэшами). Git обрабатывает это правильно, но вы снова видите все изменения в GitHub, что затрудняет просмотр. Решение состоит в том, чтобы выполнять регулярное слияние этих подтянутых в восходящем потоке коммитов вместо сквоша и слияния. Когда вы хотите объединить другую ветвь в свою в качестве зависимости git merge --squashи отменить эту единственную фиксацию, прежде чем вытащить ее из мастера, как только эта другая ветка действительно сделала ее мастером.

РЕДАКТИРОВАТЬ: другое решение - переустановить и принудительно нажать. Чистая, но переписанная история


1
Спасибо @achille, это действительно проблема с моей стороны. После отключения слияния сквоша это разрешено.
Ashvin777

0

Я не совсем уверен в теории, стоящей за этим. Но я получал это несколько раз и смог исправить это, выполнив следующие действия.

git pull --rebase

Это приведет к извлечению и объединению изменений из вашей исходной главной ветки репо (если вы указали на это)

Затем вы принудительно отправляете свои изменения в свой клонированный репозиторий github (цель)

git push -f origin master

Это гарантирует, что ваш клон github и ваше родительское репо находятся на одном уровне фиксации github, и вы не увидите никаких ненужных изменений в ветках.


0

Попробуйте выполнить следующие команды одну за другой.

git pull "latest

git reset --hard master

-1

Отказобезопасный подход, если вы слишком беспокоитесь о том, чтобы что-то испортить: перейдите к файлу и вручную удалите изменения, затем сквошируйте с помощью последней фиксации, используя

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

У меня нет конфликтов, все готово!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.