如何理解git rebase？

在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后，看起来就像development从来没有被拆分成不同的分支。

我们来一步一步拆分一个rebase操作。方案很简单：我们想用rebase集成branch-B到branch-A。

一个rebase之前的方案。

命令很简单：

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

其实就是将branchB的母分支branchA进行了integrate changes，也就是把branchB的2次commit，放在共同的起点与branchA的新commit之间，或者也可以理解成将branchA的新commit，移动到了branchB的2次commits之后。

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！

每次使用git rebase前，问自己"有没有人也正在基于这个branch写代码？"若是的话，就老老实实用merge，不要尝试rebase。
若有gitflow的经验，其实就是当你开了一个feature/foo时，若同事也开了一个feature/bar，而且你们是同时基于develop checkout出来的分支，那么当develop有hotfix merge进去时，若你想拉去最新的develop代码，就不能用git rebase，只能用merge，否则会导致同事的develop分支与我们的develop分支不同，而此时她想再与我们保持同步是很复杂的。

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

像下图这样：

实际工作中的rebase

一次完整的rebase流程

1. git checkout feature
2. git rebase master
3. resolve conflicts
4. git add .
5. git rebase --continue

如果rebase中途出现问题，可以使用git rebase --abort恢复。

git rebase的目的是保持当前feature分支与master主分支同步的另一种方式，虽然与merge的效果相同，但是比merge更加简洁高效。

为什么说rebase比merge更加简洁高效呢？

实际工作中的一个常见场景：在我们的feature开发期间，master上可能发布了很多release，修复了很多hotfix。而且可能刚好影响到了我们目前开发的feature。此时我们需要将feature的代码与master保持同步。

同步有几种方法：自己写一遍；merge；rebase。

• 自己写一遍

自己写一遍的方法是最不合理的，因为这会造成conflict，也是一种初学者容易犯的错误。

• merge

稍微有经验一点的人，可以选择merge，但是merge以后，我们在自己feature上提交的commit会被湮没在茫茫commit中，很难清晰的从git history中找到，这样我们在开发过程中就很难清晰地知道上一次commit了哪些，最后合并到master上以后，如果出现bug追溯历史commit也很困难。

• rebase

最最明智的开发者，会使用rebase的话，解决完冲突之后，就可以将我们feature上的commit全部移动到master的最新commit之后，这样我们在开发过程中，就可以清晰地看到自己在feature上的commit，发布功能之后，也可以按照时间点去review我们的这几次commit，从而快速找到问题。

期待和大家交流，共同进步，欢迎大家加入我创建的与前端开发密切相关的技术讨论小组：

• SegmentFault技术圈:ES新规范语法糖
• SegmentFault专栏：趁你还年轻，做个优秀的前端工程师
• 知乎专栏：趁你还年轻，做个优秀的前端工程师
• Github博客: 趁你还年轻233的个人博客
• 前端开发QQ群：660634678
• 微信公众号： 人兽鬼 / excellent_developers

努力成为优秀前端工程师！