Git快进VS没有快进合并
Git合并允许我们执行快速前进和没有快速前进分支合并。 任何想法何时使用快进合并以及何时使用快速合并？
当你想清楚你的功能分支时，-- --no-ff选项很有用。 因此，即使在此期间没有提交任何提交，FF也是可能的 - 您仍然希望有时在主线中提交每个提交对应于一个功能。 因此，您将一组提交作为一个单元处理一个功能分支，并将它们合并为一个单元。 从历史中可以清楚地看到，当你使用--no-ff功能进行分支合并时，
如果你不关心这样的事情 - 只要有可能，你可能会逃脱FF。 因此你会有更多svn般的工作流感。
例如，本文的作者认为--no-ff选项应该是默认的，他的推理与我上面概述的相似：
考虑一下在“特性”分支上进行的一系列次要提交共同构成一个新特性的情况：如果您只是在没有--no-ff情况下执行“git merge feature_branch”，那么从Git历史中不可能看到提交对象一起实现了一个特性 - 你必须手动读取所有的日志消息，恢复整个特性（即一组提交）是一个真正的头痛[如果不使用--no-ff ]，而它如果使用了--no-ff标志，很容易完成[因为它只是一个提交]。“
我可以举一个项目中常见的例子。
在这里，选项--no-ff （即真正的合并）创建一个新的提交与多个父母，并提供更好的历史跟踪。 否则，默认情况下是--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合并。 这意味着快速合并并不总是合格的。
也有可能人们希望拥有个性化的功能分支，代码只在一天结束时放置。 这允许以更精细的细节跟踪发展。
我不想用非工作代码来污染master开发，因此做--no-ff可能就是我们想要的。
作为一个方面说明，可能没有必要在个性化分支上提交工作代码，因为只要没有其他人在同一分支上工作，历史记录就可以重写git rebase -i并强制在服务器上。