Git がデフォルトで高速マージを実行するのはなぜですか? 質問する

ヤクブ・ナレブスキまた言及の設定merge.ff:

デフォルトでは、Git は現在のコミットの子孫であるコミットをマージするときに追加のマージコミットを作成しません。代わりに、現在のブランチの先端が早送りされます。
に設定するとfalse、この変数は、そのような場合に Git に追加のマージコミットを作成するように指示します (--no-ffコマンドラインから オプションを指定するのと同じです)。
' ' に設定するとonly、そのような早送りマージのみが許可されます (--ff-onlyコマンドラインから オプションを指定するのと同じです)。

早送りがデフォルトである理由は次のとおりです。

• 短命ブランチはGitで簡単に作成、使用できます。
• 短命なブランチは、そのブランチ内で自由に再編成できる多くのコミットを分離することが多い。
• これらのコミットは実際にはメイン ブランチの一部です。再編成されると、メイン ブランチが高速化されてそれらが含まれるようになります。

ただし、1 つのトピック/機能ブランチで反復的なワークフローが予想される場合 (つまり、マージしてからこの機能ブランチに戻ってさらにコミットを追加する場合)、機能ブランチのすべての中間コミットではなく、メイン ブランチにマージのみを含めると便利です。

この場合、設定はこの種の設定ファイル:

[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