При объединении запроса извлечения коммит появляется на GitHub, который не существует локально - PullRequest
2 голосов
/ 01 апреля 2020

Настройка

Я только что создал запрос на загрузку на GitHub со следующими двумя родителями:

2 parents: 184... + 3fb...:

  • 184 очень последний коммит на мастере, также был перенесен на origin/master
  • 3fb - самый последний коммит в моей ветви функций.

3fb - самый последний коммит на моя ветвь функций.

Я использую TravisCI и заметил, что на самом деле он запускается дважды для каждого нового PR, в этом случае он запускается для 3fb (сверху) и некоторого нового коммита, который я предполагаю это комбинация 184 и 3fb - скажем, это имеет коммит ha sh 68b.

Проблема

Когда я нажимаю Merge и опускаю получившуюся ветвь мастера, Я ожидаю увидеть 68b, но вместо этого я вижу новый (для завершения, это a64). Я не вижу 68b локально нигде!

Когда я пытаюсь проверить 68b локально, я получаю fatal: reference is not a tree: 68b.

Что здесь происходит технически? Почему я никогда не получаю этот коммит локально?

1 Ответ

2 голосов
/ 02 апреля 2020

Детали варьируются от одной системы CI к другой, но в целом системы CI создают определенный c коммит. GitHub запрос на получение , возможно, еще не имеет фиксации. 1 Так что, вероятно, Travis-CI в этом случае сделал свой собственный коммит, который он затем успешно протестировал. Это был 68b, который вы наблюдали.

[ Edit : GoodDeeds прокомментировал, что Travis-CI использует пробное слияние, которое GitHub делает , что разрушает эту конкретную теорию , Но есть еще несколько способов получить тот же результат.]

Когда я нажимаю Merge ...

Так как это происходит на самом GitHub (не на Travis), GitHub теперь делает их собственные коммиты. Поскольку каждый коммит имеет абсолютно уникальный идентификатор ha sh, этот не будет быть 68b. Редактировать : Или, если GitHub может каждый раз делать новый коммит, вместо повторного использования пробного слияния, которое они сделали ранее.

... и опускать получившийся мастер ветвь, я ожидаю увидеть 68b, но вместо этого я вижу новый (для завершения, это a64). Локально нигде не вижу 68b!

Предположительно, тогда созданный GitHub после нажатия кнопки начинается с a64. (Ограничение уникальности приводит к длинным и слишком сложным для обработки полным идентификаторам га sh. Git позволит вам сокращать до тех пор, пока результат однозначен, но фактический минимум составляет 4 символа, а не 3, который вы использовали здесь.)

Вы можете сказать GitHub, что не следует выполнять регулярное слияние, а вместо этого нужно выполнить squa sh -merge или rebase-and-merge. Ни один из них не использует какой-либо существующий коммит слияния, поэтому оба эти действия всегда приводят к новому уникальному идентификатору ha sh, которого ваш Git никогда раньше не видел.


1 Некоторые PR GitHub делают, а некоторые нет. Если GitHub действительно сделал слияние, то этот коммит доступен из GitHub. Другие хостинговые системы могут вести себя несколько иначе, и некоторые системы CI не могут использовать потенциально-условно-в любом случае обязательство, которое GitHub мог или не мог сделать на данный момент, решив просто сделать свое. Хотя я использовал Travis-CI, я никогда не исследовал его настолько, чтобы точно знать, что он здесь делает.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...