git mearge和git rebase的区别和应用场景

Posted 2023-04-01

参考技术A merge 是合并的意思，rebase是复位基底的意思。

变基 vs. 合并

现在假设我们有一个主分支 master 及一个开发分支 deve，仓库历史就像这样：

现在如果在 master 分支上git merge deve：Git 会自动根据两个分支的共同祖先即e381a81这个 commit 和两个分支的最新提交即8ab7cff和696398a进行一个三方合并，然后将合并中修改的内容生成一个新的 commit，

rebase

rebase 是什么情况呢？还是一个初始的仓库历史图：

rebase初始仓库历史

如果是在 master 分支上git rebase deve：Git 会从两个分支的共同祖先3311ba0开始提取 master 分支（当前所在分支）上的修改，即85841be、a016f64与e53ec51，再将 master 分支指向 deve 的最新提交（目标分支）即35b6708处，然后将刚刚提取的修改依次应用到这个最新提交后面。操作会舍弃 master 分支上提取的 commit，同时不会像 merge 一样生成一个合并修改内容的 commit，相当于把 master 分支（当前所在分支）上的修改在 deve 分支（目标分支）上原样复制了一遍,操作完成后的版本历史就像这样：

可以看见 master 分支从 deve 分支最新提交35b6708开始依次提交了自己的三个 commit（由于是提取修改后重新依次提交，故 commit 的 hash 码与上面的85841be、a016f64、e53ec51不同）

rebase -i

rebase 操作加上-i选项可以更直观的看见被提取的 commit 信息。

仍然在 master 分支上 rebase deve 分支，不过这次要加上-i选项，即git rebase -i deve，然后我们可以得到这样一个文本信息框

A 区域内的信息说明了这次 rebase 操作提取了哪些 commit 记录（f9a7673与edb2ba2），会连接到目标分支的哪个 commit （9c86a5c）后面。可以根据 B 区域中的命令说明修改pick为其他命令，对该次提取出来的 commit 做额外的操作

B 区域内说明了本次 rebase 操作可以选用的命令

通过:wq保存退出后，就会按照刚刚在 A 区域内设定的命令处理 commit 并 rebase。

冲突处理策略的不同

merge 遇见冲突后会直接停止，等待手动解决冲突并重新提交 commit 后，才能再次 merge

rebase 遇见冲突后会暂停当前操作，开发者可以选择手动解决冲突，然后git rebase --continue继续，或者--skip跳过（注意此操作中当前分支的修改会直接覆盖目标分支的冲突部分），亦或者--abort直接停止该次 rebase 操作

merge --no ba-ff 与 merge --ff-only 的区别

上面对 merge 的讲述都是基于其默认操作即--no-ff（git merge xxx=git merge --no-ff xxx）的说明，但是 merge 还有一种常用的选项--ff-only，那么这两种有什么区别呢？

--no-ff是 merge 的默认操作，三方合并并提交修改；而--ff-only会判断当前分支可否根据目标分支快速合并，就像下面这样

此时 deve 分支就可与 master 分支快速合并。

在 deve 分支上git merge --ff-only master，便得到合并完成后的版本历史图

可以发现--ff-only生成的历史记录和 rebase 十分相似，但是本质上--ff-only仍然是合并操作，但 rebase 并没有做合并，仅仅是提取修改到目标分支后面。

git pull

git pull 是git fetch + git merge FETCH_HEAD 的缩写。所以，默认情况下，git pull就是先fetch，然后执行merge 操作，如果加 –rebase  参数，就是使用git rebase 代替git merge。

综上所叙：merge就是产生了新的合并点，产生了痕迹，而rebase就是看起来只有commit而没有合并过，一条线。关于这个问题，作为项目管理者，有一个命令可以查询开发历史，命令 git log --oneline --graph 的时候，merge会体现出rebase的差别。

总结：选择 merge 还是 rebase？

merge 是一个合并操作，会将两个分支的修改合并在一起，默认操作的情况下会提交合并中修改的内容

merge 的提交历史忠实地记录了实际发生过什么，关注点在真实的提交历史上面

rebase 并没有进行合并操作，只是提取了当前分支的修改，将其复制在了目标分支的最新提交后面

rebase 的提交历史反映了项目过程中发生了什么，关注点在开发过程上面

merge 与 rebase 都是非常强大的分支整合命令，没有优劣之分，使用哪一个应由项目和团队的开发需求决定

merge 和 rebase 还有很多强大的选项，可以使用git help 查看

总的原则是，只对尚未推送或分享给别人的本地修改执行rebase操作清理历史，从不对已推送至别处的提交执行rebase操作，这样，你才能享受到两种方式带来的便利。

最后：一些注意点

1、使用 merge 时应考虑是采用--no-ff默认操作，生成一个对回顾提交历史并不友好的合并记录，还是采用--ff-only方式

2、rebase 操作会丢弃当前分支已提交的 commit，故不要在已经 push 到远程，和其他人正在协作开发的分支上执行 rebase 操作

3、与远程仓库同步时，使用 pull 命令默认进行了git fetch + git merge --no-ff两个操作，可以通过加上--rebase命令将 fetch 后的 merge 操作改为 rebase 操作，或者仅仅 'git fetch remoteName',然后才思考采取哪种整合策略git merge(or rebase) origin/master

开发与 commit 时注意自己此时在哪个分支上

当有修改未 commit 时，不能进行 rebase 操作，此时可以考虑先用git stash命令暂存

git各种命令 & git merge和git rebase的区别

 

 git merge 和 rebase的区别：

http://blog.csdn.net/jollyjumper/article/details/24743751

 

对于两个分支而言，rebase和merge没有区别，但是rebase更干净，因为log hisitory是线性的，但commit不一定按日期先后排，而是local commit总在后面,merge之后history变得比较复杂，但是commit按日期排序,stackoverflow上有个图示很好:

http://stackoverflow.com/questions/16666089/whats-the-difference-between-git-merge-and-git-rebase

这篇博客则说适用场景,认为产品OEM保留分支时适用rebase,功能分支合并到主分支用merge。

http://blog.csdn.net/rryqsh/article/details/8230560