Merge和Rebase概念概述

首先我们应该明白git rebase是用来处理git merge命令所处理的同样的问题。这两个命令都用于把一个分支的变更整合进另一个分支，只不过他们达成同样目的的方式不同。

请考虑这个场景，当你开始在一个专有的分支开发新的功能时，另一位团队成员更新了main分支的内容。这将会造成一个分叉的提交历史，对于任何一个使用Git作为代码协作工具的人来说都不会陌生。

现在假设main分支内新增的内容与你正在开发的新功能有关。为了把main分支里新增的代码应用在你的feature分支，你有两种方法：merge 和 rebase。

使用merge

最简单的方法就是把main分支合并进功能分支：

git checkout feature
git merge main

或者用下面这样的单行命令：

git merge feature main

这会在feature分支中创建一个合并提交，这次提交会连结两个分支的提交历史，在分支图示结构中看起来像下面这样：

合并操作很友好，因为它没有破坏性。现存的分支历史不会发生什么改变。这一特性避免了rebase操作的所有缺陷（下面会详细讨论）。

但是另一方面来说，这也意味着每当feature分支需要应用上游分支的更改时，都会在提交历史上增加一个无关的提交历史。如果main分支的更新非常活跃，这种操作也会对功能分支的提交历史产生相当程度的污染。虽然通过复杂的git log命令可以减轻这种提交历史的混乱现状，但仍然会让其他开发者对于提交历史感到费解。

使用rebase

为了替代merge操作，你也可以把feature分支的提交历史rebase到main分支的提交历史顶端：

git checkout feature
git rebase main

这些操作会把feature分支的起始历史放到main分支的最后一次提交之上，也达成了使用main分支中新代码的目的。但是，相对于merge操作中新建一个合并提交，rebase操作会通过为原始分支的每次提交创建全新的提交，从而重写原始分支的提交历史。

使用rebase操作的最大好处在于你可以让项目提交历史变得非常干净整洁。首先，它消除了git merge操作所需创建的没有必要的合并提交。其次，正如上图所示，rebase会造就一个线性的项目提交历史——也就是说你可以从feature分支的顶部开始向下查找到分支的起始点，而不会碰到任何历史分叉。这在使用git log,git bisect以及gitk等命令时更简单。

不过为了获得这种便于理解的提交历史，却需要付出两种代价：安全性和可追溯性。如果不能遵循rebase的黄金法则，重写项目提交历史会为协作工作流程带来潜在的灾难性后果。再次，rebase操作丢失了合并提交能够提供的上下文信息——所以你就无法知道功能分支是什么时候应用了上游分支的变更。

rebase操作黄金法则

一旦你明白了什么是rebase，接下来最重要的事情就是要了解什么情况下不应该使用它。关于git rebase的黄金法则就是永远不要在公共分支上使用它。

举例来说，想一想如果把main分支rebase到feature分支之上，会发生什么：

rebase命令会把main分支中的所有提交都放到feature分支的提交记录顶端。问题在于这个改变目前只出现在你的本地仓库。其他开发者仍然在原来的main分支上进行开发。由于rebase会产生全新的提交记录，所以Git会认为现在你本地的main分支与所有其他人的产生了分叉。

唯一能够同步两个不同的main分支的方式就是将其合并起来，这会产生一个冗余的合并提交，并且这次合并中的大部分提交内容都是相同的（以前的main分支和你本地的main分支中）。不用说，这下可真让人疑惑。

所以任何时候要执行git rebase命令之前，先确认“是否有其他人也正在使用此分支？”如果答案是确定的，那么你就应该停下来想想有没有其他非破坏性的操作（比如试试git revert命令）。除了这样的情况之外，重写提交历史都是安全的。

总结

如果你希望一个干净线性的提交历史，而不是含有众多合并提交相互交织的提交历史，那么应该尝试在整合分支时使用git rebase而不是git merge。

反过来说，如果你想要保存完整的提交历史，避免重写公共提交的历史，仍然可以坚持使用git merge。两者都可以，但至少你现在拥有了另一个选项，可以见机利用 git rebase的优势。