git rebase VS git merge
git rebase 和 git merge是git合并分支的两种方式，然而他们却采用了不同的工作方式，以下面的一个工作场景说明其区别：
场景：
下图所示：当feature分支有新的需求提交，同时，master 分支也有修改。
这时，如果要将master 上新的提交合并到你的feature分支上，我们有两种选择：merging or rebasing
merge
执行以下命令：
git checkout feature
git merge master
或者执行：
git merge master feature此时在feature上git 自动会产生一个新的commit(merge commit)
look like this：
marge 特点：自动创建一个新的commit
当合并时遇到冲突，修改后重新commit即可
优点：将commit的实际情况进行记录，便于以后查看
缺点：由于每次merge会自动产生一个merge commit，所以在使用一些git 的GUI tools，如果commit频繁，这样会使得feature分支很杂乱，这时可以考虑使用rebase来进行合并处理。
rebase
本质是变基，即找公共祖先
执行以下命令：
git checkout feature
git rebase master
look like this:
rebase 特点：将commit历史进行合并
优点：项目历史比较简单，少了merge commit
缺点：当发生冲突时不容易定位问题，因为re-write了history
合并时如果出现冲突需要按照如下步骤解决
- 修改冲突部分
- git add
git rebase --continue- （如果第三步无效可以执行
git rebase --skip）
不要在git add 之后习惯性的执行 git commit命令
The Golden Rule of Rebasing rebase 的黄金法则
never use it on public branches(不要在公共分支上使用)
比如说如下场景：如图所示
如果你rebase master 到你的feature分支：
rebase 将所有master的commit移动到你的feature 的顶端。问题是：其他人还在original master上开发，由于你使用了rebase移动了master，git 会认为你的主分支的历史与其他人的有分歧，会产生冲突。
所以在执行git rebase 之前 需要认真考虑，
会有其他人看这个分支么？
if YES 不要采用这种带有破坏性的修改commit 历史的rebase命令
if NO ok，随你便，可以使用rebase
结论：
想要干净的历史，少了merge commit的线性历史树，选择git rebase
而如果你想保留历史记录，并且想要避免重写commit history的风险，使用git merge