变基本名 rebase ，也不知道是谁给它起了这么拗口的名字。
上一篇文章我们学习了 merge 操作，知道了两个分支之间同步代码可以使用git merge命令，但是 merge 命令有一个小缺点让一部分完美主义者无法接受，那就是每次 merge 完成之后，都会生成一个新的 commit。
假如频繁的从 master 分支同步代码到 develop 分支，那 develop 分支上会多出来很多 merge 节点，这些节点有些人觉得很多余，污染了提交历史，让它阅读起来很困难。也有一部分人觉得应该保留开发过程中的每一个操作，方便追踪问题，所以不应该去掉这些节点。两种想法没有对错，仅看个人习惯，如果想同步代码后不产生新的节点，那可以使用一个新的命令git rebase。
流程
base 基本点，在 Git 中指分支开始分叉的那个节点。
re 重新设置。
rebase 可以理解为重新设置基本点，也就是修改分支分叉的位置。
1. 切换到目标分支
使用git checkout develop命令，切换到 develop 分支，develop 可以替换为任何目标分支。
2. 变基
使用git rebase master命令，将 master 代码 rebase 到 master，如果没有冲突则 rebase 完成。
3. 解决冲突
如果产生了冲突，则需要先解决冲突，冲突解决完毕后，使用git rebase --continue命令继续执行 rebase 操作。如果想终止此次 rebase 可以使用git rebase --abort命令。
原理
下图展示的是将 master 分支代码 rebase 到 develop 分支的过程：
从图中我们可以发现，在执行 rebase 之前，develop 分支是基于 C2 节点的，执行 rebase 操作后，develop 分支的基点移动到了 C4，而 develop 分支的 C5 和 C6 节点会重新在 C4 之后再重放一遍。
C5 和 C6 节点看起来是从 C2 节点后移动到了 C4 节点后，但实际上 Git 并没有移动 C5 和 C6 节点，而是在 C4 节点后，又提交了两个跟 C5 和 C6 相同的节点 C5’ 和 C6’，C5 和 C5’ 除了 commit id 不同，其余完全一样。
rebase 黄金法则
永远不要对一个公共分支执行 rebase 操作。
在执行 rebase 操作前，请默念此法则三遍。一旦对公共分支执行了 rebase 操作，那整个分支将会变得不可维护。