Я намагаюся переглянути запит на притягнення на GitHub до гілки, яка не є головним. Цільова гілка опинилася за головним, і запит на витяг показав коміти від master, тож я об'єднав master і пересунув його до GitHub, але коміти і розходження для них все ще з’являються у запиті на витяг після оновлення. Я подвійно перевірив, що відділення на GitHub має команду від майстра. Чому вони все ще з'являються у запиті на виклик?

Я також перевірив запит на витяг локально, і він відображає лише об'єднані коміти.

Схоже, запит на витяг не відслідковує зміни цільової гілки (я зв’язався із службою підтримки GitHub і 18 листопада 2014 року отримав відповідь про те, що це задумано).

Однак ви можете отримати його, щоб показати вам оновлені зміни, виконавши наступне:

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

Замінити githuburl, org, repo, targetbranch, і currentbranchв разі необхідності.

Або як зазначено у своїй відповіді hexsprite, ви також можете змусити її оновити, натиснувши Editна PR і тимчасово змінивши базу на іншу гілку та назад. Це створює попередження:

Ви впевнені, що хочете змінити базу?

Деякі комісії зі старої базової гілки можуть бути видалені із часової шкали, а старі коментарі до огляду можуть застаріти.

І залишить дві записи журналу в PR:

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

Підводячи підсумок, GitHub не перезавантажує історію фіксацій автоматично в запитах на виклик. Найпростіші рішення:

Рішення 1: База даних

Припустимо, ви хочете об'єднатись 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.

У ваш ~/.gitconfigфайл потрібно додати :

[rebase]
    autosquash = true

Це автоматично досягне того ж, що і ця відповідь .

Я дістала це звідси .

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

Більше інформації можна отримати тут: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

Загальні предки на основі різниць здаються небезпечними. Я хотів би, щоб у GitHub була можливість зробити більш стандартний 3-позиційний PR на основі злиття.

Один із способів виправити це - це git rebase targetbranchв цьому PR. Тоді git push --force targetbranchGithub покаже правильні зобов'язання та розходження. Будьте обережні з цим, якщо не знаєте, що робите. Можливо, спочатку огляньте тестову гілку, щоб зробити ребауз, а потім git diff targetbranchпереконатися, що це все-таки ви хочете.

Це відбувається з GitHub, коли ви сквош здійснюєте об'єднані з цільової гілки.

Я використовував сквош і злиття з Github як стратегію злиття за замовчуванням, включаючи злиття з цільовою гілкою. Це вводить нову фіксацію, і GitHub не визнає, що ця обрізана фіксація є такою ж, як та, яка вже є у master (але з різними хешами). Git обробляє це належним чином, але ви знову бачите всі зміни в GitHub, що робить їх дратівливим для перегляду. Рішення полягає в регулярному злитті цих витягнутих у верхівку комітетів замість сквош і злиття. Коли ви хочете об'єднатись у іншу гілку до вашої як залежність git merge --squashі повернути це єдине зобов’язання перед тим, як витягнути з головного, коли інша гілка насправді зробила його освоєнням.

EDIT: ще одне рішення - перезагрузка та примушування. Чиста, але переписана історія

Я не зовсім впевнений у теорії, що стоїть за цим. Але я це отримував кілька разів і міг це виправити, зробивши наступне.

git pull --rebase

Це дозволить отримати та об'єднати зміни з початкового відділення головного репо (якщо у вас є на це пункт)

Потім ви натискаєте свої зміни насильно до вашого клонованого сховища Github (цільового)

git push -f origin master

Це дозволить переконатися, що ваш клон Github та ваше батьківське репо знаходяться на одному рівні фіксації github, і ви не побачите зайвих змін у галузях.

Спробуйте наведені нижче команди по черзі.

git pull "latest

git reset --hard master

Неможливо безпечний підхід, якщо ви занадто турбуєтесь про збиття речей: перейдіть до файлу та видаліть зміни вручну, а потім видаліть останню версію за допомогою

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})"

У мене немає конфліктів, вам добре йти!