git - merge 分支时使用 pull 和 no-ff 时快进

Question

我的工作流程中有许多短期分支，我希望将它们分开。所以，我打算使用 git config --add merge.ff false。但是，当我进行 pull 时(我理解为获取+ merge )——然后我想要一个快进行为，以避免不必要的额外提交。

这是好事吗？这可能吗？

Answer 1

注意:Git 2.0(2014 年第 2 季度)将以 commit b814da8 引入配置 push.ff:

pull.ff::

By default, Git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded.

• When set to false, this variable tells Git to create an extra merge commit in such a case (equivalent to giving the --no-ff option from the command line).
• When set to only, only such fast-forward merges are allowed (equivalent to giving the --ff-only option from the command line).

---

初始答案(2012 年 10 月)

尝试:

git pull --ff

它应该优先于您的 merge 配置设置。
它会将 --ff 选项传递给 git pull 命令中的底层 merge 。

不过，请注意 --no-ff 选项，如“Understanding the Git Workflow”中所述

With enough flags you can force Git to act the way you think it should instead of the way it wants to. But that’s like using a screwdriver like a hammer; it gets the job done, but it’s done poorly, takes longer, and damages the screwdriver.

Consider how a common Git workflow falls apart.

Create a branch off Master, 
do work, 
and merge it back into Master when you’re done

Most of the time this behaves as you expect because Master changed since you branched. Then one day you merge a feature branch into Master, but Master hasn’t diverged. Instead of creating a merge commit, Git points Master to the latest commit on the feature branch, or “fast forwards.” (Diagram)

Unfortunately, your feature branch contained checkpoint commits, frequent commits that back up your work but captures the code in an unstable state. Now these commits are indistinguishable from Master’s stable commits. You could easily roll back into a disaster.

So you add a new rule: “When you merge in your feature branch, use –no-ff to force a new commit.” This gets the job done, and you move on.

Then one day you discover a critical bug in production, and you need to track down when it was introduced. You run bisect but keep landing on checkpoint commits. You give up and investigate by hand.

You narrow the bug to a single file. You run blame to see how it changed in the last 48 hours. You know it’s impossible, but blame reports the file hasn’t been touched in weeks.
It turns out blame reports changes for the time of the initial commit, not when merged. Your first checkpoint commit modified this file weeks ago, but the change was merged in today.

The no-ff band-aid, broken bisect, and blame mysteries are all symptoms that you’re using a screwdriver as a hammer.

更多信息，请参见:

• "With dvcs/git, is a single commit preferred over multiple, small, thematic commits? "
• "git newbie question - Commit style: Commit all changed files at once or one at a time? "