前言
今天想把本地的两个提交压缩成一个提交,再推送到远程。用的是rebase命令解决的,于是乎又捡起了之前的遗留问题:rebase和 merge 有什么区别?
用的是idea内置的git插件,先把idea官网对 “update project” 选择 “merge” 或 “rebase” 的等价命令行掌握

直观感受
- 出现下图的“Merge”提交的commit,出现的场景是:两个同事在同一个分支上开发
- 同事A基于 commit9 增量添加了 commit10,并push
- 同事B基于 commit9 增量添加了 commit11
- 同事B从远程 git pull --no-rebase (或 git fetch git merge)
- 此时发现在 commit9 后除了同事B,还有同事A有提交
- 于是同事B(自己)的commit 11 和 同事A的 commit 10 按时间顺序排列后,再新增了个“merge” 节点

对比 rebase 和 merge
在如上的合并场景的时候,merge 会比 rebase 多一个节点,起到了标识合并过程的作用。同时从idea的提交线路上看,也能溯源到自己的提交,同时区分了别人的提交。
合并的什么时候用 rebase 什么时候用 merge
自己一个人开发的分支直接用rebase即可
多人在一个分支上协作
- 改不同模块:rebase merge 都可以
- 改相同模块:merge 比较好,出了问题好溯源(merge标识了合并的时间点)
特性分支上线
- merge 进 master
rebase 其他应用场景
- 修改本地commit信息
- 将本地多个commit 合并成一个
理解 rebase
rebase 更像是一种修改历史的操作,英语直译就是“变基”。看下面的例子
-
rebase 前

-
rebase 后

在 15 和 17 中间插入了个 16,也就修改了当前分支的历史。同理也就能解释 rebase 能修改提交过的内容了。
本文探讨了Git的rebase和merge命令的区别。直观感受上,merge会在提交历史中增加一个合并节点,而rebase则可以平滑历史,使得提交线更简洁。在个人开发时,推荐使用rebase;多人协作时,若修改不同模块两者皆可,修改相同模块建议用merge以方便追溯。rebase还有用于修改本地commit信息和合并提交的功能。
768

被折叠的 条评论
为什么被折叠?



