在merge PR的过程中，rebase and merge会产生冲突，因此需要补充一下Git rebase的知识点。
- Understanding Rebase (And Merge) in Git
- Merging vs. Rebasing
- webstorm 的 Rebase Current onto selected什么操作？
- rebase and merge 一个Pull request做了什么操作？
Understanding Rebase (And Merge) in Git
merge 是Git中最简单也是最常用的集成change的方法，但是这并不是唯一的一种方式。 Rebase是另外一种可选的但是略微高级的集成方式。
合并提交的case
通常情况下，一个由人类认真创建的commit，是一个有意义的单元：它仅仅包含相关的change并且每个commit都伴随着一个comment。 有一种merge commit可以让所有comments丢失：Git自动创建的commit，并且由Git填充所有的differ change。没有语义，没有主题。当然，这些独立commits的内容是保留的。但是history分成了注释的，分离的有意义的commit，由于这个原因，在一次merge commit中不会保留。 这就是为什么有些人不喜欢merge，喜欢rebase的原因。
Rebase之美
与一笼统把commits塞到一个commit不同，一个rebase会保留原始的commits。 项目的历史是一条单的，直线。没有任何迹象表明它在某个时候拆分出一个分支来。
我们来一步一步拆分一个rebase操作。方案很简单：我们想用rebase集成branch-B到branch-A。
命令很简单：
git rebase branch-B
复制代码首先，线条开始分支后，Git将"undo"所有的branch-A上的commits（在共同的祖提交后）。当然，它不会丢弃它们，而是临时将它们存了起来。
其次，它会应用我们想集成的来自branch-B的commits。此使，两个分支是相同的。
最后，branch-A的新commits重新被应用，但是在一个新的位置，在branch-B的后面。（they are rebased）。 结果就是development在一条直线上开发。不是一个commit包含了所有的改变，而是让原始commit结构保持原样。
下面尝试开BranchA，BranchB两个分支，然后基于webstorm的Version Control，观察git rebase操作会不会有上述的变化。
BranchA
BranchB
Rebase BranchA onto branchB
rebase的是谁，就修改的是谁 onto的是谁，谁就是被rebase的分支的新commits
其实，rebase只做了一件事：更新base branch！（重点！重点！重点！）
而想将谁的更新内容作为新的base branch的提交，就将作为topicBranch。
非常重要的命令。
git checkout baseBranch
git rebase topicBranch
复制代码再说的通俗一点，其实就是：挑了一个branch，把它的特性拿过来，放在我的新特性之前。
Merging vs. Rebasing
看完上面这篇文章后，并没有搞清楚rebase做了什么操作，所以还是需要多读一些文章。
- 对于初学者来说，git rebase命令就像一个magic voodoo
- merge和rebase都是用来从一个分支到另一个分支integrate changes的，只是方式不同
Merge Option
git checkout feature
git merge master
复制代码
git merge master feature
复制代码会有一个'merge commit', 但是merge是非常安全的，不会像rebase有很多陷阱。 但是若master非常活跃，每次merge都会有要给'merge commit'，会导致feature的commit history很脏。
Rebase Option
git checkout feature
git rebase master
复制代码-
feature从master tip处开始合并master上的commits
-
重写project的history
-
rebase后，project的history更加干净了。没了多余的'merge commit'，并且成了一条线。
-
rebase 需要遵循Golden Rule of Rebasing，否则会导致灾难性的合作workflow。
-
rebase 会丢失掉merge commit，导致看不到之后合并到feature的commit。
灵活一点的Rebasing
- 选择特定的commits移动到新分支，加一个i选项
- fixup某一个提交
git checkout feature
git rebase -i master
复制代码pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
复制代码pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
复制代码
Golden Rule of Rebasing
永远不要在public 分支上使用git rebase！
Force-Pushing
若想将rebased的master分支推到远程仓库，Git 将会阻止你，因为它与远程的master分支冲突了。但是，你可以force push。
# 这个命令一定要小心使用
git push --force
复制代码- 只有100%确定自己在做什么时再force，否则会让团队的人很困惑
- 若是想将某个feature远程分支彻底替换掉，可以这样做。
下面尝试开master，feture两个分支，然后基于webstorm的Version Control，观察git rebase操作会不会有上述的变化。
master
feature
git checkout feature
git rebase master
# resolve conflict1
git rebase --continue
# resolve confict2
git rebase --continue
复制代码Rebase feature onto master
webstorm 的 Rebase Current onto selected什么操作？
可以理解成下图这样。
Rebase feature onto master
Current在WebStorm中指右下角的branch，selected一般指的original branch。
rebase and merge 一个Pull request做了什么操作？
git checkout feature
git rebase master
复制代码像下图这样：
