title: Git Rebase和Merge的用法
categories: 后端
tags:
- Git

Rebase和Merge是什么？

merge和rebase的作用都是合并两个分支，其区别在于：

                     A---B---C topic
                    /         \
               D---E---F---G---H master

在topic分支，想要引入master分支的F、G commit上的内容，可以用merge，然而merge的缺点是引入了一次不必要的合并记录：

                     A--B--C--X topic
                    /       / \
               D---E---F---G---H master

其实仔细想一下就会发现，在引入master分支的F、G commit这个问题上，我们并没有要求两个分支必须进行交汇(join)，我们只是想避免最终的merge conflict而已。

rebase是另一个选项。rebase的含义是改变当前分支branch out的位置。这个时候进行rebase其实意味着，将topic分支branch out的位置从E改为G，如图：

                             A---B---C topic
                            /
               D---E---F---G master

在这个过程中会解决引入F、G导致的冲突，同时没有多余的history join。但是rebase的缺点是，改变了当前分支branch out的节点。如果这个信息对你很重要的话，那么rebase应该不是你想要的。rebase过程中也会有多次解决同一个地方的冲突的问题，不过可以用squash之类的选项解决。个人并不认为这个是rebase的主要问题。

以上部分内容来自知乎的回答： https://www.zhihu.com/question/36509119/answer/131513261

正确使用rebase的开发流程

1. 第一天创建了一个feature分支开发自己的功能，并且进行了几次commit

   C1 -- C2 -- C3 (master)
   <br /> -- F1 -- F2 (feature)

2. 多次commit后需要把多个commit合并（参考我之前的一篇博客：如何使用sourcetree合并多个commit）

   C1 -- C2 -- C3 (master)
   <br /> -- F12 (feature)

3. 当功能开发完成后合并到主分支时，主分支已经有其他人的commit：

   C1 -- C2 -- C3 -- C4 -- C5 (master)
   <br /> -- F12 (feature)

4. 此时先在主分支上rebase,变成了下面这样:

   C1 -- C2 -- C3 -- C4 -- C5 (master)
   <br /> -- F12 (feature)

5. 然后再merge到主分支：

   C1 -- C2 -- C3 -- C4 -- C5 ---- C6 (master)
   \ /
   -- F12 (feature)

注意点：

• 合并多个commit是为了在rebase的时候避免解决多次冲突

以上内容总结了这篇知乎回答：

部分有意义的回答

rebase的最大好处并不是消除merge，而是避免merge的交织。

简要来说，就是在merge进被合分支（如master）之前，最好将自己的分支给rebase到最新的被合分支（如master）上，然后用pull request创建merge请求。

我个人一般在pull request里面还是采用普通的merge，当然可能有的小伙伴喜欢rebase merge等，我觉得要看具体情况。

其实本文的关键就是合理利用 rebase和merge来避免git历史提交里的无意义的“交织”。

来自一个用户名的知乎回答

参考

1. 知乎问题：在开发过程中使用 git rebase 还是 git merge，优缺点分别是什么？

2. 知乎专栏：git merge和git rebase的区别, 切记：永远用rebase