git rebase和merge --no-ff之间的区别是什么

Question

两种方法似乎都有相同的目的，以保持清晰的历史：

• Git Rebase

• No fast forward（--no-ff）

因此，如果我在功能分支上进行了变基，那么在合并回主分支时是否还需要--no-ff？

更新：

在我看来，在变形，快进和非快进合并之间存在混淆，基本上图（图3.28）在此链接http://git-scm.com/book/en/Git-Branching-Rebasing中显示正常的合并结果与merge相同--no-ff从此链接的顶部答案Why does git fast-forward merges by default?

Answer 1

这取决于您希望历史记录的外观。

一个非常简单的例子：

git merge --no-ff

*   33ad16c (HEAD, master) Merge branch 'feature-1'
|\  
| * e61c6a6 Various bug fixes
| * e15a356 Started feature
|/  
* 38b8ada Initial commit

git rebase

* e61c6a6 (HEAD, master) Various bug fixes
* e15a356 Started feature
* 38b8ada Initial commit

这两个历史记录反映了完全相同的提交但使用--no-ff，第一个历史记录清楚地表明了2个提交实际上是同一组工作的一部分。这使您可以准确了解哪些功能进入了哪些功能。这样可以更轻松地回滚更改或在浏览历史记录时给自己上下文。

rebase历史没有显示出这种区别，因此无法看到任何工作分组。它让每个人都承诺掌握它。

您使用--no-ff获得的空合并提交也提供了一个挂起提交消息的有用位置，而普通提交使您无法轻松地说“此提交合并于feature-x的工作”，这也有助于历史

Answer 2

通常，如果您合并某个功能分支，则要使用--no-ff 强制执行创建显式合并提交。

如果您只是在某个分支上工作，通常需要避免合并可能由git pull引起的提交。因此，您使用git rebase或git pull --rebase 而不是创建合并提交并获得干净的历史记录。