Git 快进 VS 没有快进合并

Git fast forward VS no fast forward merge

提问by Chau Chee Yang

Git merge allow us to perform fast forward and no fast fast forward branch merging. Any ideas when to use fast forward merge and when to use no fast forward merge?

Git 合并允许我们执行快进而不是快进分支合并。什么时候使用快进合并，什么时候不使用快进合并？

回答by Ivan Danilov

The --no-ffoption is useful when you want to have a clear notion of your feature branch. So even if in the meantime no commits were made, FF is possible - you still want sometimes to have each commit in the mainline correspond to one feature. So you treat a feature branch with a bunch of commits as a single unit, and merge them as a single unit. It is clear from your history when you do feature branch merging with --no-ff.

--no-ff当您想要对功能分支有一个清晰的概念时，该选项很有用。因此，即使在此期间没有进行任何提交，FF 也是可能的 - 您有时仍然希望主线中的每个提交对应一个功能。因此，您将具有一堆提交的功能分支视为一个单元，并将它们合并为一个单元。当您将功能分支与--no-ff.

If you do not care about such thing - you could probably get away with FF whenever it is possible. Thus you will have more svn-like feeling of workflow.

如果你不关心这样的事情 - 只要有可能，你可能会逃脱 FF。因此，您将有更多类似 svn 的工作流程感觉。

For example, the author of this articlethinks that --no-ffoption should be default and his reasoning is close to that I outlined above:

例如，这篇文章的作者认为--no-ffoption应该是default，他的推理与我上面概述的很接近：

Consider the situation where a series of minor commits on the "feature" branch collectively make up one new feature: If you just do "git merge feature_branch" without --no-ff, "it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache [if --no-ffis not used], whereas it is easily done if the --no-ffflag was used [because it's just one commit]."

考虑在“功能”分支上的一系列次要提交共同构成一个新功能的情况：如果您只执行“git merge feature_branch”而没有--no-ff，“从 Git 历史记录中不可能看到哪些提交对象一起具有实现了一个功能——你必须手动读取所有的日志消息。恢复整个功能（即一组提交）是一个真正令人头疼的问题[如果--no-ff没有使用]，而如果使用了--no-ff标志，则很容易做到[因为这只是一次提交]。”

回答by themefield

I can give an example commonly seen in project.

我可以举一个项目中常见的例子。

Here, option --no-ff(i.e. true merge) creates a new commit with multiple parents, and provides a better history tracking. Otherwise, --ff(i.e. fast-forward merge) is by default.

在这里，选项--no-ff（即true merge）创建一个具有多个父项的新提交，并提供更好的历史跟踪。否则，--ff（即快进合并）是默认的。

$ git checkout master
$ git checkout -b newFeature
$ ...
$ git commit -m 'work from day 1'
$ ...
$ git commit -m 'work from day 2'
$ ...
$ git commit -m 'finish the feature'
$ git checkout master
$ git merge --no-ff newFeature -m 'add new feature'
$ git log
// something like below
commit 'add new feature'         // => commit created at merge with proper message
commit 'finish the feature'
commit 'work from day 2'
commit 'work from day 1'
$ gitk                           // => see details with graph

$ git checkout -b anotherFeature        // => create a new branch (*)
$ ...
$ git commit -m 'work from day 3'
$ ...
$ git commit -m 'work from day 4'
$ ...
$ git commit -m 'finish another feature'
$ git checkout master
$ git merge anotherFeature       // --ff is by default, message will be ignored
$ git log
// something like below
commit 'work from day 4'
commit 'work from day 3'
commit 'add new feature'
commit 'finish the feature'
commit ...
$ gitk                           // => see details with graph

(*) Note that here if the newFeaturebranch is re-used, instead of creating a new branch, git will have to do a --no-ffmerge anyway. This means fast forward merge is not always eligible.

(*) 注意这里如果newFeature分支被重用，而不是创建一个新分支，git--no-ff无论如何都必须进行合并。这意味着快进合并并不总是符合条件。

回答by Pritom Nandy

When we work on development environment and merge our code to staging/production branch then Git no fast forward can be a better option. Usually when we work in development branch for a single feature we tend to have multiple commits. Tracking changes with multiple commits can be inconvenient later on. If we merge with staging/production branch using Git no fast forward then it will have only 1 commit. Now anytime we want to revert the feature, just revert that commit. Life is easy.

当我们在开发环境中工作并将我们的代码合并到暂存/生产分支时，Git no fast forward 可能是更好的选择。通常，当我们在开发分支中为单个功能工作时，我们往往会进行多次提交。以后跟踪多个提交的更改可能会很不方便。如果我们使用 Git 与暂存/生产分支合并，没有快进，那么它将只有 1 次提交。现在，无论何时我们想要还原该功能，只需还原该提交即可。生活很容易。

回答by g24l

It is possible also that one may want to have personalized feature branches where code is just placed at the end of day. That permits to track development in finer detail.

也有可能希望拥有个性化的功能分支，其中代码只是在一天结束时放置。这允许更详细地跟踪开发。

I would not want to pollute master development with non-working code, thus doing --no-ff may just be what one is looking for.

我不想用非工作代码污染主开发，因此 --no-ff 可能正是人们正在寻找的。

As a side note, it may not be necessary to commit working code on a personalized branch, since history can be rewritten git rebase -iand forced on the server as long as nobody else is working on that same branch.

附带说明一下，可能没有必要在个性化分支上提交工作代码，因为git rebase -i只要没有其他人在同一分支上工作，就可以在服务器上重写和强制历史记录。