rebase-将功能分支合并为主要分支的操作。

永远不要合并那些已经推送到公共仓库的更新。

如果你把派生看作是推送前清理提交历史的手段，只派生那些没有公开的提交对象，是没有问题的。如果我们把已经公开的提交对象结合起来，有人基于这些提交对象进行了后续的开发工作，就会出现令人沮丧的麻烦。

参考链接:Git分支-分支派生

操作步骤:

5.1 rebase

当前分支:dev_1(粗体)

基底分支:发育

操作:右键单击develop分支，将出现以下弹出框。选择“导出当前要开发的变更”，然后“确认导出”。如果有冲突，解决冲突。然后重复上面的右键操作，在弹出框中选择“继续衍生”。推导完成后，dev_1分支运行到develop分支的下游，是一条直线。

5.2合并

当前分支:开发(粗体)

操作:右键单击dev_1分支，会出现如下弹出框。选择“合并dev_1开发”，然后“确认合并”快进。合并完成后，develop分支指向dev_1分支的最新提交。

5.3删除dev_1分支

功能分支合并到主分支后，就没有意义了，可以删除。

在C4的基础上重新键入C3生成的变更补丁。在Git中，这个操作更像rebase。

其原理是回到两个分支的最近祖先，根据当前分支(即要派生的分支dev_1)的后续提交对象(这里只有一个C3)生成一系列文件补丁，然后以基础分支(即develop)的最后一个提交对象C4为新起点，逐个应用之前准备好的补丁文件。最后，将生成一个新的合并提交对象C3，从而重写dev_1的提交历史，并使其成为develop分支的直接下游，如下所示。

现在回到开发分支，做一个快进合并。此时,“开发”分支指向C3。

由于develop当前分支的submission对象就在要合并的dev_1分支的正上游，Git只需要将develop分支的指针直接向右移动即可。换句话说，如果再往下走一个分支就可以到达另一个分支，那么Git在合并两个分支的时候就简单的将指针向右移动，因为在这一条单线的历史分支中没有需要解决的差异，所以这个合并过程可以称为快进。