Почему git выполняет ускоренное слияние по умолчанию?

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

Warning: У небыстрой переадресации есть и потенциальные побочные эффекты. Пожалуйста, просмотрите https://sandofsky.com/blog/git-workflow.html, избегайте "no-ff" с его "checkpoint commits", которые нарушают bisect или blame, и тщательно обдумайте, должен ли он быть вашим подходом по умолчанию для master.

^{(От nvie. com, Vincent Driessen, сообщение "Успешная модель ветвления в Git")}

Включение готовой функции в develop

Готовые функции могут быть слиты в ветку develop, чтобы добавить их в предстоящий релиз:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

Флаг --no-ff заставляет слияние всегда создавать новый объект коммита, даже если слияние может быть выполнено с ускоренной перемоткой. Это позволяет избежать потери информации об историческом существовании ветки фич и сгруппировать все коммиты, которые вместе добавили фичу.

Jakub Narębski также упоминает о config merge.ff:

По умолчанию Git не создаёт дополнительный коммит при слиянии коммита, который является потомком текущего коммита. Вместо этого происходит ускоренная перемотка на вершину текущей ветви.
При значении false эта переменная указывает Git'у создать дополнительный коммит слияния в таком случае (эквивалентно указанию опции --no-ff из командной строки).
Если установлено значение 'only', разрешено только такое ускоренное слияние (эквивалентно передаче опции --ff-only из командной строки).

По умолчанию используется ускоренное слияние, потому что:

• короткоживущие ветви очень легко создавать и использовать в Git'е
• короткоживущие ветви часто изолируют множество коммитов, которые могут быть свободно реорганизованы в пределах этой ветви
• эти коммиты фактически являются частью основной ветви: после реорганизации основная ветвь быстро пересылается, чтобы включить их.

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

В этом случае вы можете установить такой конфигурационный файл:

[branch "master"]
# This is the list of cmdline options that should be added to git-merge 
# when I merge commits into the master branch.

# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.

# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.

mergeoptions = --no-commit --no-ff

OP добавляет в комментариях:

Я вижу некоторый смысл в ускоренной перемотке для [короткоживущих] веток, но если сделать её действием по умолчанию, это значит, что git предполагает, что у вас... часто есть [короткоживущие] ветки. Разумно?

Jefromi отвечает:

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

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

В более общем смысле я добавлю:

это действительно зависит от вашего рабочего процесса разработки:

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

См. статью "Когда вам следует ветвиться?"

На самом деле, если рассматривать модель ветвления Mercurial, то в ее основе лежит одна ветвь на репозиторий (хотя вы можете создавать анонимные головы, закладки и даже именованные ветви)
. "Git и Mercurial - сравнение и противопоставление".

Mercurial, по умолчанию, использует анонимные облегченные кодовые линии, которые в его терминологии называются "головами".
Git использует легковесные именованные ветви, с инъективным отображением для сопоставления имен ветвей в удаленном репозитории с именами удаленно отслеживаемых ветвей.
Git "заставляет" вас называть ветви (за исключением одной безымянной ветви, которая называется "detached HEAD"), но я думаю, что это лучше работает с рабочими процессами с большим количеством ветвей, такими как рабочий процесс с тематическими ветвями, подразумевающий несколько ветвей в одном репозитории.