在合并分支时使用pull和no-ff时快进 [英] fast forward when using pull and no-ff when merging branch

问题描述

我的工作流程中有许多短命的分支，我希望他们分开。所以，我打算使用 git config --add merge.ff false 。然而，当我正在做一个拉（我理解的是获取+合并） - 然后我想要一个快进行为，以避免不必要的额外提交。

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

解决方案

注意：Git 2.0（2014年第二季度）将引入 commit b814da8 a config push.ff ：

  pull.ff :: 
  

默认情况下，Git在合并作为当前提交的后代的提交时不会创建额外的合并提交。

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

---

初步答案（2012年10月）

试试看：

  git pull --ff 
  

它应优先考虑您的合并配置设置。

它将在git pull命令中将 - ff 选项传递给基础合并。

请注意 - no-ff 选项，如了解Git工作流程

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

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

 创建一个关闭Master的分支，
工作，
并将它合并回Master， '做完了
  

大多数情况下，自从你分支后改变了。然后有一天你将一个功能分支合并到Master中，但是Master并没有发生分歧。 （图）

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

因此，您添加了一条新规则：当您在功能分支中合并时，使用 -no- ff 强制执行新的提交。这样做可以完成工作，然后继续。

然后有一天，生产，你需要追踪它的推出时间。您运行 bisect ，但保持登陆检查点提交。你放弃并手工调查。

您将错误缩小为单个文件。您运行 blame 以查看它在过去48小时内的变化情况。你知道这是不可能的，但是 blame 报告这个文件在几个星期内还没有被触及。

原来责备报告初始提交时间的变化，而不是合并时的变化。您的第一次检查点提交在几周前修改了此文件，但是更改在今天已合并。 $ b

no-ff 如果您使用螺丝刀作为锤子，那么您可能会遇到这种情况。

如需了解更多信息，请参阅：

• git newbie question - Commit style：一次或一次提交所有已更改的文件？

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.

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

解决方案

Note: Git 2.0 (Q2 2014) will introduce with commit b814da8 a config 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).

---

Initial answer (October 2012)

Try a:

git pull --ff

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

Beware of the --no-ff option though, as mentioned in "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.

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

这篇关于在合并分支时使用pull和no-ff时快进的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！