Можно ли сказать Github, что моя ветка была объединена с ведущим ведущим сервером?

Чтобы ответить на заданные вопросы,

Можно ли сказать Github, что моя ветка была объединена с ведущим ведущим сервером? [...] Почему Github потерял информацию о том, что функция была объединена в master через предварительный PR?

Да, безусловно, можно записать слияние. Как обычно.

Кто-то решил сказать git (и github) не записывать это, поэтому эффекты появились в основной ветке восходящего потока без следа того, откуда они пришли.

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

В любом случае, после получения результата у вас теперь есть незаписанное слияние, что нормально, чисто и красиво, если вы никогда не пытаетесь слить последующую работу, по-прежнему основанную на незарегистрированном родителе.

Что с этим делать?

Выбранный вами вариант, который также может быть более гибким (он обрабатывает истории нескольких фиксаций feature1..feature2), может быть полностью записан как

git rebase --onto master feature1 feature2

как правило, самый чистый: апстрим отказался от вашей истории feature1, поэтому вы отказываетесь от нее, переустанавливая функцию feature2 на контент, который у них есть сейчас.

Если по какой-то причине вы действительно не хотите отказываться от истории feature1 в своем собственном репозитории - возможно, у вас есть больше, чем просто feature2, основанная на старой подсказке feature1, и перебазирование станет утомительным - вы также можете добавить локальная запись слияния.

echo $(git rev-parse origin/master origin/master~ feature1) >>.git/info/grafts

Это сообщает локальному git, что текущий исходный / главный коммит имеет в качестве родителей как его записанный первый родительский коммит, так и локальный коммит feature1. Поскольку апстрим отказался от фиксации feature1, а вы этого не сделали, все механизмы git теперь работают правильно как здесь, так и вверх по течению.

В разных проектах существуют разные правила того, на чем должны основываться истории запросов на вытягивание, некоторые хотят, чтобы все основывалось на каком-то последнем совете, другие хотят, чтобы все основывалось на теге базы обслуживания, третьим нужны исправления ошибок на основе фиксации, которая привела к ошибке (я думаю, это должно быть гораздо более распространенным явлением). Некоторых это не особо заботит, потому что все настолько хорошо знакомы с базой кода, что перебазирование по желанию остается самым простым.

Но здесь важно то, что rebase-before-pushing - это ваша последняя возможность убедиться, что то, что вы нажимаете, в точности правильное. Это отличная привычка, и трансплантаты прекрасно работают в этом рабочем процессе.

Github теперь поддерживает 3 метода для объединения запросов на вытягивание:

• Слияние: создает коммит слияния (без перемотки вперед) + извлекает все исходные коммиты из ветви PR.
• Сжатие и слияние: создает одну фиксацию.
• Rebase and merge: создается столько коммитов, сколько PR-ветка, но они перемещаются на главную.

Только регулярное слияние сохраняет информацию о том, что мои локальные коммиты были частью PR, объединенного с master. Если бы он использовался, я бы не столкнулся с проблемой, описанной в вопросе.

Два других метода теряют это знание - и я ничего не могу сделать, чтобы создать его задним числом (без изменения ведущего мастера). Это цена, которую нужно заплатить за более простую историю.

Интуитивно понятно, что для git, чтобы знать, что основная фиксация восходящего потока U связана с моей локальной фиксацией L, должна быть стрелка, указывающая от U к L.

Концептуально есть два способа добиться этого.

Во-первых, U может иметь двух родителей: один соединяет его с L, другой - со всеми предыдущими коммитами в восходящем направлении master. Именно это и делает техника Github merge.

Во-вторых, U может иметь L в качестве единственного родителя, если L уже указывает на все предыдущие коммиты в восходящем направлении master. Github мог бы поддержать это, разрешив ускоренную перемотку вперед с помощью техники слияния, но он решил этого не делать.

Если PR Github объединяется либо с сжатием и слиянием, либо с перебазированием и слиянием, все коммиты, созданные на главном сервере восходящего потока, имеют только одного родителя; стрелок между ними и моими локальными коммитами нет.

Редактировать:

Кроме того, теперь я считаю, что потеря истории, о которой я спрашивал, не имела большого значения. IIUC, конфликты, с которыми я мог бы столкнуться с git cherry-pick, на самом деле такие же, как конфликты с git rebase, если master был подключен к feature2 через обычную фиксацию слияния. И если бы у меня было более одной фиксации, разделенной на отдельный PR, вишневый справился бы с этим легко тоже.

Основная основная причина ваших проблем заключается в том, что после завершения запроса на вытягивание для feature (функциональная ветка с одной откатной фиксацией) возникает фиксация слияния, переходящая в master. Вот схема, показывающая, как выглядят master и feature2 после завершения feature запроса на перенос в master:

master:   ... A -- B -- C -- M
                         \
feature:                  D
                           \
feature2:                   E

Здесь мы видим, что feature отделился от master при фиксации C, а feature2 является просто продолжением feature с одной дополнительной фиксацией. Фиксация слияния M находится в верхней части master и представляет всю дополнительную работу, проделанную в feature. Обратите внимание, что это фиксация слияния и, следовательно, не имеет ничего общего с историей feature2.

Затем вы выполнили следующую перебазировку feature2 на master:

git checkout feature2
git rebase master

После этого перебазирования feature2 будет выглядеть так:

feature2: ... A -- B -- C -- M -- D' -- E'

Обратите внимание, что фиксация слияния остается частью истории. Хотя с функциональной точки зрения это может показаться ненужным, потому что фиксация D содержит все необходимое для совершения этой фиксации слияния, эта фиксация все равно появляется.

Если вам интересно, что вы можете сделать, чтобы этого избежать, можно было бы сохранить историю master linear. Недостатком был запрос на перенос, который завершился фиксацией слияния. Если бы вместо этого вы играли коммиты из feature непосредственно поверх master, у вас бы не было этой проблемы. Рассмотрим следующие команды:

git checkout feature
git rebase master

Затем выполните быстрое слияние master с feature:

git checkout master
git merge feature

В результате master и feature2 выглядели бы так:

master:   ... A -- B -- C -- D
feature2: ... A -- B -- C -- D -- E

Теперь, если вы объедините feature2 в master, Git просто воспроизведет E фиксацию, вместо того, чтобы возвращаться к исходной точке, откуда master и feature расходились.

Да нормально. Но git отвечает на этот вопрос, глядя на историю, а не на изменения. Если вы используете сквош Github (то есть уничтожаете историю), вы теряете возможность использовать эту историю; а именно способность git определять, существует ли уже часть этой истории в восходящем потоке.

Основываясь на диаграмме, созданной Тимом Бигелейзеном:

master:   ... A -- B -- C -- M
                         \  /
feature:                  D
                           \
feature2:                   E

Когда вы переходите к переустановке feature2 на master, вы должны на самом деле увидеть эту историю:

master:   ... A -- B -- C -- M
                         \  /  \
feature:                  D     \
                                 \
feature2:                         E'

Потому что rebase никогда не воссоздает фиксацию, которая уже существует в месте назначения. Он будет знать, что D уже в истории магистра.

Когда вы перебазировали feature2 на master, вы увидели коммиты, которые логически уже присутствовали в master. Это может произойти только в следующем сценарии.

Перед слиянием вы переписываете некоторые коммиты в функции:

                 D'   feature
               / 
... A -- B -- C 
               \  
                D 
                 \
                  E  feature2

выполнить слияние:

                 D'   feature
               /   \
... A -- B -- C --- M   master
               \  
                D 
                 \
                  E  feature2

затем попробовал перебазировать feature2 поверх master:

                 D'   feature
               /   \
... A -- B -- C --- M   master
                     \  
                      D'' 
                       \
                        E'  feature2