Git快进VS没有快进合并

Git合并允许我们执行快速转发，而不能进行快速快进分支合并。有什么想法何时使用快速前向合并以及何时不使用快速前向合并？

--no-ff当您希望对功能分支有清晰的概念时，此选项很有用。因此，即使在此期间未进行任何提交，也可以使用FF-您仍然希望有时主干中的每个提交都对应一个功能。因此，您将具有一堆提交的功能分支视为一个单元，并将它们合并为一个单元。从您的历史记录中可以很明显地看出，您与合并功能时--no-ff。

如果您不关心此类问题，则可以尽可能避免使用FF。因此，您将拥有类似svn的工作流程感。

例如，本文的作者认为该--no-ff选项应为默认选项，其推理与我上面概述的相近：

考虑以下情况：“功能”分支上的一系列次要提交共同构成了一个新功能：如果不使用进行“ git merge feature_branch” --no-ff，则“从Git历史中无法看到哪些提交对象一起拥有”实现了一个功能-您将必须手动读取所有日志消息。恢复整个功能（即一组提交）是一件令人头疼的事[如果--no-ff未使用]，但是如果使用了该--no-ff标志则很容易做到[因为这只是一次提交]。”

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

在这里，选项--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

（*）注意，在这里如果newFeature分支被重用，而不是创建一个新分支，git仍然必须进行--no-ff合并。这意味着快速前进合并并不总是符合条件。

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

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

我不想用不起作用的代码来污染主开发，因此--no-ff可能正是人们想要的。

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