Git：合并分支----git rebase命令的使用_rebase dev onto master

前言

在 Git 中整合来自不同分支的修改主要有两种方法：merge 以及 rebase。 在本博客将介绍“变基”的两种基本使用方法，以及指出在何种情况下应避免使用它。

git merge 命令的使用可以参考：https://blog.csdn.net/qq_42780289/article/details/97945300

一、git rebase命令的应用

1、示例一

开发任务在B2分叉成两个不同分支，又各自提交了更新。

你可以提取在 B4 中引入的补丁和修改，然后在 B3 的基础上应用一次。 在 Git 中，这种操作就叫做 变基。 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

在上面的例子中，运行：

$ git checkout dev
$ git rebase master
1
2

或者不用切换分支，采用 git rebase [basebranch] [topicbranch] 的方式，basebranch是目的分支（即本例的 master 分支），topicbranch是源分支（即本例的 dev 分支），总的意思是将 dev 分支中的修改变基到 master 分支上。这样做能省去你先切换到 dev 分支，再对其执行变基命令的多个步骤。

即等价于：

$ git rebase master dev
1

它的原理是首先找到这两个分支（即源分支 dev 和目的分支 master）的最近共同祖先 B2，然后源分支 dev 对比当前提交相对于该祖先的历次提交，提取相应的修改并存为临时文件，接着将源分支 dev 指向目标基底 B3, 最后以此将之前另存为临时文件的修改依序应用到 B3，从而产生了B4‘。（有点绕，要理解清楚！！）

现在回到 master 分支，进行一次快进合并。

$ git checkout master
$ git merge dev
1
2

请注意，无论是通过 git rebase 命令变基，还是通过 git merge 命令三方合并，整合的最终结果提交始终是一样的，只不过提交历史不同罢了。 变基是将一系列提交按照原有次序依次应用到另一分支上，然后合并把最终结果合在一起。

2、示例二

在对两个分支进行变基时，所生成的“重放”并不一定要在目标分支上应用，你也可以指定另外的一个分支进行应用。

假设你希望将 next 中的修改合并到主分支并发布，但暂时并不想合并 dev 中的修改。 这时，你就可以使用 git rebase 命令的 --onto 选项，选中在 next 分支里但不在 dev 分支里的修改（即 B5 和 B6），将它们在 master 分支上重放：

$ git rebase --onto master dev next
1

以上命令的意思是：“取出 next 分支，找出处于 next 分支和 dev 分支的共同祖先之后的修改，然后把它们在 master 分支上重放一遍”。

现在回到 master 分支，进行一次快进合并。

$ git checkout master
$ git merge next
1
2

接下来还可以把 dev 分支的修改也整合进来，这里就不演示了，方法和示例一是一样的。

最后，分支中的修改都已经整合到主分支里了，你可以删除这两个分支：

$ git branch -d dev
$ git branch -d next
1
2

二、git rebase命令不适用的情况

要使用 git rebase 命令得遵守一条准则：

不要对在你的仓库外有副本的分支执行变基。

打个比方，你在本地有 master 分支，在远程库有相应的副本 master 分支，这种情况下就不要对本地 master 在最近一次push之前的提交历史执行变基。

变基操作的实质是丢弃一些现有的提交，然后相应地新建一些内容一样但实际上不同的提交（最明显的就是 commit-id 改变了）。 如果你已经将提交推送至某个仓库，而其他人也已经从该仓库拉取提交并进行了后续工作，此时，如果你用 git rebase 命令重新整理了提交并再次推送，你的同伴因此将不得不再次将他们手头的工作与你的提交进行整合，如果接下来你还要拉取并整合他们修改过的提交，事情就会变得一团糟。