Почему запрос на извлечение приводит к тому, что форк находится позади восходящего потока?

Question

Предположим, что существует репозиторий GitHub с именем upstream/project. Допустим, у меня есть его форк с именем fork/project. Я фиксирую некоторые изменения в fork/project и инициирую запрос на получение upstream/project. Как только запрос на получение принят, почему fork/project становится 1 коммитом за upstream/project?

Код в репозитории upstream теперь соответствует коду в моей ветке. Почему я должен вытащить снова из репозитория upstream, чтобы оказаться в том же состоянии? Не мог ли вышестоящий репозиторий быть точно синхронизирован с вилкой, вместо того, чтобы «перезагружать» его?

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

Answer 1

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

Если то, что вы действительно спрашиваете, это:

почему upstream не слился с fast-forward?

Стратегия Merge-commit / no-fast-forward очень полезна для объединения PR, потому что она позволяет возвращать изменения всего за один шаг (потому что есть только один коммит, независимо от того, сколько было в оригинале ветка). Одного этого достаточно, чтобы превратить его в стратегию перехода.

Answer 2

Как намекает SLaks в комментарии, разница в коммите слияния, сделанном на upstream/project.

Когда ваш запрос на получение ответа принят, ветки объединяются, и на upstream/project выполняется фиксация, но fork/project не знает об этом, прежде чем вы снова извлекаете из апстрима.

Когда вы вытягиваете, fork/project начинается с извлечения этого нового коммита, а затем просто ускоренной перемотки вперед без необходимости слияния. Только тогда оба дерева идентичны.

О стратегии:

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

Чтобы перейти к части «стратегия», уже есть много сравнений с отличными ответами, просто ищите в строке «дебаты о слиянии / перебазировании».