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

fast forward when using pull and no-ff when merging branch

提问by Vikash

I have many short-lived branches in my workflow and I would like them to be separated. So, I plan to use git config --add merge.ff false. However, when I am doing a pull (which I understand is fetch+merge) - then I want a fast-forward behavior, to avoid unnecessary extra commit here.

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

Is this a good thing to do? Is this possible?

这是一件好事吗？这可能吗？

回答by VonC

Note: Git 2.0 (Q2 2014) will introduce with commit b814da8a config push.ff:

注意：Git 2.0（2014 年第二季度）将通过提交 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-onlyoption from the command line).

默认情况下，Git 在合并作为当前提交的后代的提交时不会创建额外的合并提交。相反，当前分支的尖端是快进的。

• 当设置为 false 时，这个变量告诉 Git 在这种情况下创建一个额外的合并提交（相当于从命令行提供 --no-ff 选项）。
• 当设置为 only 时，只允许这样的快进合并（相当于--ff-only从命令行提供选项）。

---

---

Initial answer (October 2012)

初步答复（2012 年 10 月）

Try a:

尝试一个：

git pull --ff

It should take precedence on your merge config setting.
It will pass the --ffoption to the underlying merge within the git pull command.

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

Beware of the --no-ffoption though, as mentioned in "Understanding the Git Workflow"

但请注意该--no-ff选项，如“了解 Git 工作流程”中所述

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.

有了足够多的标志，你就可以强制 Git 按照你认为应该的方式而不是它想要的方式行事。但这就像使用像锤子一样的螺丝刀；它完成了工作，但做得不好，需要更长的时间，并且会损坏螺丝刀。

考虑一下常见的 Git 工作流程是如何分崩离析的。

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-ffto 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 bisectbut keep landing on checkpoint commits. You give up and investigate by hand.

You narrow the bug to a single file. You run blameto see how it changed in the last 48 hours. You know it's impossible, but blamereports the file hasn't been touched in weeks.
It turns out blamereports 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-ffband-aid, broken bisect, and blame mysteries are all symptoms that you're using a screwdriver as a hammer.

大多数情况下，这会按照您的预期运行，因为 Master 在您分支后发生了变化。然后有一天你将一个功能分支合并到 Master 中，但 Master 没有分叉。Git 没有创建合并提交，而是将 Master 指向功能分支上的最新提交，或“快进”。（图表）

不幸的是，您的功能分支包含检查点提交，频繁提交备份您的工作但捕获处于不稳定状态的代码。现在这些提交与 Master 的稳定提交没有区别。您可以轻松地回滚到灾难中。

所以你添加了一个新规则：“当你在你的功能分支中合并时，使用–no-ff来强制一个新的提交。” 这完成了工作，然后您继续前进。

然后有一天你在生产中发现了一个严重的错误，你需要追踪它是什么时候被引入的。您运行bisect但继续登陆检查点提交。您放弃并手动调查。

您将错误缩小到单个文件。您运行blame以查看它在过去 48 小时内的变化情况。你知道这是不可能的，但blame报告说这个文件已经好几个星期没有动过了。
结果blame是在初始提交时报告更改，而不是在合并时。几周前您的第一次检查点提交修改了此文件，但今天已合并更改。

该no-ff创可贴，打破平分，并指责奥秘是所有的症状，您使用螺丝刀作为一个锤子。

For more, see:

有关更多信息，请参阅：

• "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?"

• “使用 dvcs/git，单个提交是否优于多个、小的、主题提交？”
• “ git 新手问题 - 提交风格：一次提交所有更改的文件还是一次提交一个？”