背景

git中分支合并的两种方式：merge(合并)和rebase(变基)，平时工作中，基本都是使用merge操作，还没有使用过rebase,前几天项目发版执行分支merge操作时，由于某种原因不能再提交新的commit，所以就想到了rebase，将学习过程记录一下。

目前项目的分支及提交情况如下：

feature分支是本次版本的新功能分支，main分支也存在一些新commit，主要是解决上个版本的线上bug，要发布新版本，需要将feature分支合并到main分支，就以该例子，分析一下merge和rebase是如何进行分支合并的。

merge

执行如下命令，将分支合并

git checkout dev
git merge master

这将在 dev 分支中创建一个新的“合并提交”，将两个分支的历史记录联系在一起，分支结构如下：

merge操作是一种非破坏性操作，会保留所有的commit；但会产生一条新的无关的commit，如果master的commit很多，则会污染dev分支的commit，导致分支的commit记录比较乱。

rebase

执行如下命令，将分支变基

git checkout dev
git rebase master

这会将整个 dev 分支移动到 master 分支的顶端，从而有效地将所有新commit合并到 master .但是，变基不是合并commit，而是通过为原始分支中的每个commit创建全新的提交来重写项目历史记录。

git会从master和dev的共同祖先开始提取dev分支上的修改，也就是C和D、E三个提交，先提取到。然后将dev分支指向master分支的最新提交上，也就是B。最后把提取的C和D、E应用到B上（依次拿B和C、D、内容分别比较，处理冲突后生成新的C’和D’、E‘）。

rebase操作并不会产生新的commit,并且从上图也可以看出，rebase操作后，会使commit记录更加清晰。但是，这也会导致提交记录无法追溯。

黄金法则

什么情况适合使用merge，什么情况下适合rebase，下面是一些黄金法则： * 使用 merge 保留分支完整历史，适用于公共分支合并。 * 使用 rebase 保持干净的提交历史，适用于私有分支和个人工作。