项目实战—IDEA中分析Git Merge 和 Rebase的区别

目录

问题

分析问题

merge​​​​​​​

rebase

 总结

---

问题

之前和同事一直讨论关于merge和rebase的区别，我们中的大多数人都是使用的merge的方式，对与rebase的方式不是很理解。感觉有了merge了，为啥还会使用rebase呢？

对于这样的困惑，我相信大家也会有。于是结合工程实践和idea的git可视化插件来说明我们在项目开发中使用的区别。
 

分析问题

merge

如下图，切换到我们本地feature的分支，打开git log可以看到我们平时开发提交的代码都是一条主线上的，只是自己开发的话是没有问题的。因为我们自己提交代码到release，然后从release拉取代码开发，开发好了合并到release，依次循环。自己和自己永远是不会冲突的。

但是多人开发的时候就会出现问题，如下图。我们在开发的时候，另外一个同事开发了一个功能并合并到了release，他和我同时修改了一个文件的同一块代码，这两个文件就会冲突。

如下图4和4`的提交发生冲突了。

 

此时如果想将代码合并到release必须解决冲突，我将release的代码合并到自己feature分支。这样就有了最新的代码，就不会覆盖或者丢弃同事的代码了。然后在idea中手动解决冲突提交代码。 如下：

解决完冲突后可以看到，同事2修改的代码会在一个新的分支中，然后产生一个新的merge commit在我们的feature分支中。 

 

那么如果有多个同事提交代码，再合并到我们的feature中，那么会产生更多的分支结构 ：

rebase

如果此时我们同rebase，看看将会产生什么样的分支结构图。

先Reset分支到merge之前的提交： 

 

切换到自己的feature分支，点击需要Rebase的分支，就是release分支：

然后选择下面的选项，"onto Selected"就是以release的分支为基础分支进行变基。

同样需要解决冲突： 

 

此时打开git log，可以看到同事2修改的代码跑到前面去了：  

rebase变基，就是将我们的拉取的基础分支的共同版本提交版本3进行变换，以新得提交版本4作为基点拉取到feature分支中，可以看出此时的代码分支更加干净：

 总结

1. merge和rebase都是合并代码，在处理代码冲突和最终合并新旧代码的目的上没有太大区别;

2. merge会产出一个新的merge的commit，分支会比较复杂，而rebase之后的分支就一条比较简明干净；

3. rebase在push代码的时候更加清晰，没有多余额merge commit,自己修改的代码也会放在前面。