GitHub Объединить филиал 'master'

Пробовал Git и Github после многих лет использования svn. Кажется, у меня есть основы, но один предмет меня смущает.

  • UserA вносит изменения в FileA и нажимает на удаленный сервер (GitHub)

  • UserB вносит изменения в FileB. Сначала он вытаскивает с удаленных сервер, а затем перетаскивает его изменение в FileB на удаленный сервер

  • История фиксации GitHub показывает нажатие на UserA и нажатие кнопки UserB

  • Однако есть дополнительная запись в истории фиксации из UserB, которая называется "Объединить ветку" https://github.com/xxx/yyy ', Просмотр diff в Github показывает, что это точная копия изменений, внесенных UserA в FileA

Почему этот дубликат показан - оба нажатия от UserA до FileA и записей мастера объединения Merge идентичны... второй кажется мне лишним.

Ответы

Ответ 1

Каждая версия ( "commit" ), хранящаяся в git, образует часть графика, и часто полезно подумать о том, что вы делаете в git в терминах этого графика.

Когда начнется UserA, скажем, что было создано только два коммита, которые мы будем называть P и Q:

P--Q (master)

Затем он модифицирует FileA, этапы, которые изменяются, и создает коммит, который представляет новое состояние исходного кода - скажем, что commit называется R. У этого есть один родитель, который является фиксацией Q:

P--Q--R (master)

После успешного нажатия, граф фиксации для репозитория GitHub выглядит одинаково.

UserB запущен с той же историей:

P--Q (master)

... но создал другую фиксацию, называемую S, которая имеет свою измененную версию FileB:

P--Q--S (master)

UserB пытается нажать на GitHub, но нажатие будет отклонено - если вы не "навязываете" push, вам не разрешено обновлять удаленную ветку, если только ваша версия не включает всю историю на этом удаленном сервере филиал. Итак, UserB вытаскивает из GitHub. Натяжение действительно состоит из двух шагов, выборки и слияния. Извлеките обновления origin/master, которые похожи на кэш состояния удаленной ветки master с удаленного устройства origin. (Это пример "ветки удаленного отслеживания".)

P--Q--S (master)
    \
      R (origin/master)

История в этом графе расходится, поэтому слияние пытается объединить эти две истории, создав слияние (например, M), у которого есть как S, так и R как родители, и, мы надеемся, представляет изменения из обе ветки:

P--Q--S--M (master)
    \   /
     \ /
      R (origin/master)

Когда GitHub показывает вам diff, который представляет изменения, внесенные фиксацией, он прост в случае фиксации с одним родителем - он может просто выполнить diff от этой версии. Однако в случае коммита, такого как M, с несколькими родителями, он должен выбрать родителя, чтобы показать diff. Это объясняет, почему diff, показанный для фиксации слияния M, может показаться таким же, как показанный для одного из S или R. Записи в git определяются точным состоянием исходного дерева, а не изменениями, которые получили дерево в этом состоянии.