Какова цель отдельного коммита слияния в git?

Question

Когда вы объединяете две ветви вместе, git создает отдельный коммит с сообщением типа Merge branch 'master' into my-branch. Для нетривиального слияния мне ясно, что это полезно: оно хранит историю того, как вещи были объединены, отдельно от любых других изменений. Но когда слияние тривиально (например, когда две ветви не влияют ни на какие общие файлы), какова цель отдельного коммита слияния?

Вы можете избежать этого коммита с помощью git merge --no-commit. Затем вы можете добавить «реальное» изменение в этот коммит. Таким образом вы избежите, казалось бы, бесполезного дополнительного коммита. Но справочная страница предупреждает об этом:

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

Почему это?

С коммитами с реальными изменениями в них, помеченными как o, и коммитами только слиянием как X, это разница между этими двумя ситуациями:

o---o-o-o---o--- master
 \   \   \   \
  o-o-X-o-X-o-X-o--- my-feature


o---o-o-o---o--- master
 \   \   \   \
  o-o-o---o---o--- my-feature

Почему первый предпочитается второму?

PS: Предположим, что my-feature является публичной веткой, которую также используют другие люди, поэтому rebase не подойдет.

Answer 1

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

Возможные ситуации, когда вам будет выгодно иметь отдельные коммиты слияния:

1. Вы пытаетесь выяснить, в каком коммите произошла ошибка. Если вы не разделяете слияние и обычные коммиты, трудно определить, вызвало ли слияние эту ошибку, или реальные изменения от этого коммита.
2. Вы хотите отменить изменение, сделанное коммитом. Что должно произойти, когда вы отменяете коммит, который является слиянием и также содержит изменения самостоятельно? Вы хотите отменить только изменения, или просто слияние, или оба? Если только один из них, как их отделить?

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

Answer 2

На моем рабочем месте «центральным» хранилищем является сервер SVN. Я использую git через git-svn.

SVN (очевидно) не выполняет быстрое слияние. Поэтому, чтобы иметь возможность реплицировать мою локальную историю на сервер, я делаю все слияния, которые станут видимыми извне.

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

Когда вы выполняете перемотку вперед, информация о том, когда произошла интеграция, теряется - в истории нет смысла говорить «вот когда X стал Y» со связанным сообщением.

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

На ваш другой вопрос - «почему в коммите слияния должны быть только небольшие изменения», ответ заключается в том, что коммит слияния может иметь большое различие в отношении любого или всех его родителей. Таким образом, если вы добавите туда значительную другую работу, очень трудно распутать, была ли проблема интеграцией или одним из добавленных вами новых изменений. Если вы поместите коммит либо на одного из родителей, либо после слияния, разделение на части будет упрощено, возможен перенос изменений с помощью вишневого пика, вы можете отменить слияние, не теряя функций, и т. Д.