Избегайте добавления пустых слияний

Question

У меня есть проект, который также является пакетом NuGet.Из-за этого он живет в 2 ветках: master, который используется для выпуска новых официальных версий, и development, где происходит фактическая разработка.Когда мы хотим выпустить новую версию, мы просто объединяем коммиты от development до master.
Наш процесс выпуска пакетов включает (и требует) фиксацию коммитов.Теперь проблема в том, что в прошлом, когда мы сливались из development в master, история git для master содержала только коммиты из development, коммитов слияния не было (поэтому всегда добавлялись n обязуется в истории).Тем не менее, в какой-то момент кто-то в команде начал делать странные вещи с ветвями в этом хранилище, и теперь, когда мы сливаемся с master, сверху добавляется пустой коммит слияния (так что это приводит к n+1 коммитам, добавленным к masterистория).Он не содержит измененных файлов, он просто есть.Это немного раздражает, но реальная проблема здесь в том, что теперь тег пакета заканчивается на коммите слияния, чего мы не хотим.
Вопрос в том, как это можно исправить, чтобы мы больше не получали это пустое слияние.фиксирует каждый раз, когда ветка объединяется в master ветку?

Answer 1

Из того, что вы описываете, история master отличается от истории development. Это расхождение может быть таким же маленьким, как и коммит, который был перебазирован для изменения сообщения о коммите, автора или выхода из системы. Даже если деревья двух ветвей абсолютно одинаковы, история остается другой . Следовательно, git не может выполнить слияние ускоренной перемотки, когда оно только обновляет master, чтобы указать на последний коммит в development. Вместо этого создается реальный коммит слияния для записи разницы в истории между master и development.

Если приведенное выше описание верно, вы можете легко исправить эту ситуацию, объединяя master в development один раз, в идеале сразу после объединения development в master.

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

Answer 2

То, что вы хотите сделать, это выполнить быстрое слияние.Быстрое слияние вперед может иметь место только в том случае, если все изменения в вашей ветке development были сделаны поверх последнего коммита master.В этом случае, если вы вызовете git merge с --ff-only, указатель ветки master будет установлен непосредственно на последний коммит development.

См. этот вопрос исвязанные вопросы для подробностей о слияниях ff и non-ff.

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

Помните, чтоесли вы используете GitLab, GitHub или что-то подобное, могут быть настройки, которые будут применены, если принудительные коммиты слияния выполняются или нет.