Сравнение Github для 2 веток неверен?

Когда я делаю сравнение Github между master и другой ветвью A, Github, похоже, сравнивает версию HEAD A со старшей версией master

Я просмотрел его, и из того, что я могу сказать, звучит так, как будто Гитуб сравнивает ветвь A с общим предком master. На самом деле это не сравнение с тем, что в настоящее время находится на HEAD мастера.

Есть ли способ разграничить HEAD мастера от HEAD Branch A в Github?

Если нет, почему бы и нет? Это похоже на функцию, которую каждый разработчик захочет сделать. Или есть какой-то процесс, который должен быть сделан, что мне, возможно, не хватает? Я хотел бы иметь возможность создавать запрос Pull непосредственно из одного из этих различий.

EDIT: Здесь приведен пример репо, который показывает проблему

https://github.com/bradparks/test_github_diff_view

Я создал новое репо, содержащее один файл, README.md
Я установил этот файл в одну строку v100.
Затем я разветкил мастер в новую ветвь A и изменил строку на `v200 '
Затем я изменил значение в главной ветки на "v300", а затем сравнил 2 ветки с помощью ссылки сравнения

https://github.com/bradparks/test_github_diff_view/compare/A

и я вижу следующий неожиданный результат. Почему он не отличается от v300 вместо v100?

Ответ 1

Есть ли способ отличить ГОЛОВУ мастера от ГОЛОВА Ветви А в Github?

Сентябрь 2018: да: GitHub теперь явно поддерживает " сравнения Git с тремя точками и двумя точками сравнения ". Смотрите пример здесь.
Кейсуке упоминает в комментариях аналогичную инициативу на Bitbucket.

Оригинальный ответ 2015:

Нет: как упомянуто в " Сравнении GitHub для текущих версий веток ", GitHub поддерживает только спецификацию ярлыка диапазона тройных точек (...).
То есть:

Эта форма предназначена для просмотра изменений на ветки, содержащей и вплоть до второй, начиная с общего предка обоих.

" git diff A...B " эквивалентно " git diff $(git-merge-base AB) B ".
Вы можете опустить любой из них, что имеет тот же эффект, что и использование HEAD.

Официальная справка GitHub упоминает эту функцию как:

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

В этом сценарии ветвь PR начинается с master (или в любом случае должна быть перебазирована поверх master), что означает, что master HEAD является базой между master и веткой PR.

Но когда две ветки разветкились, сравнение уже происходит не между HEADs, а между одним общим предком и одним HEAD: git diff $(git-merge-base master B) B

Примечание: даже если бы вы указали два SHA1 напрямую, как это четко задокументировано в разделе " Сравнение коммитов ", это все равно сделало бы git diff $(git-merge-base AB) B
Это не сделало бы разницу между двумя коммитами.

Ответ 2

Есть ли способ разграничить HEAD мастера от HEAD Branch A в Гитубе?

[ EDIT: Нет, я ошибся. У меня был URL-адрес, который выглядел так, как будто это будет правильно, а diff на странице выглядел правильно, но это был несчастный случай. Если вы действительно хотите узнать больше, проверьте историю этого ответа.]

Ответ 3

Еще одна мысль. Если вы хотите создать запрос на перенос от разницы между вашей работой и головкой ведущей ветки (в соответствии с операцией op), то вам нужно сначала сбросить свою ветвь с главной ветки git rebase <master>, а затем сделать запрос на растяжение.

Но вам, как правило, этого не нужно, Git очень умный слияниями и, как правило, сможет добавить вашу работу в ведущую ветвь, как вы хотите, добавив ее, даже если вы не сначала перебазируете,

Ответ 4

Это выглядит для меня сломанным (в настоящее время) так же, как описано здесь. Я построил небольшое тестовое репо: один репо, один файл, одну ветку, три коммита, и никакой радости...

Кажется, не имеет значения, если вы укажете явный базовый хэш коммита ветвления с помощью синтаксиса с тремя точками; Сравнивать мне все еще кажется, чтобы отличаться от точки, где две ветки были последними одинаковыми.

FWIW, я вижу такое же поведение на GitLab. Я понятия не имею, почему это так.

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

Тестовое репо: https://github.com/ChrisRus/github-compare