git的rebase和merge

会重写提交历史，使之变得线性，因此，它可以创建一个更整洁、更易于阅读的提交历史。这也可以避免合并提交（merge commits）的产生。

初始时共有四个分支：master、branch_rebase、branch_merge、branch_target

rebase

在分支branch_rebase上执行git rebase master。

上图中的line 6告诉我们 rebase 没有一帆风顺，有冲突发生，当然，此冲突是故意设计的，用意就是模拟真实的场景，因为实际的场景中，冲突是不可避免的。接下来，我们来解决冲突：


保留双方更改，当然了这里是测试，冲突解决的随便了一点，如果在正式的开发中，冲突的解决需要保证项目运行无误，且业务逻辑符合预期。回到 git 中：


执行 git add <冲突文件>；执行 git rebase --continue，此时会让我们编写 commit message，这个取决于编辑器的配置，我用的 vscode，所以可以看到弹出的文件，如果编辑器是 vim 的话，也会相应的提示的；我们写好 message 信息之后，关闭，可以看到 rebase 成功。当然如果我们不想这么麻烦，可以在add之后执行 git rebase --skip。


接下来，把目光转移到分支上的效果上。


我们画一个简答的图来做一个对比相比会更加清晰

上图中(圆圈中的内容用提交的message来标识而不是哈希码，这样更加直观)上面是变基之前的分支状况，下面是变基之后的分支情况，一目了然，有所改变的分支是 branch_rebase，branch_target 分支没有变化。此外还要注意一点，rebase 1这条message的内容和我们处理冲突时的提交信息一致，所以可以等效看做在 branch_target 分支上把 branch_rebase分支的提交以此加上去，其中第一次的提交由于处理冲突可以自定义，如果想保持不变也可以不做更改。

merge