每次在合并分支代码，都不知道是该用git merge 还是rebase, 非常抓瞎，分不清它们的区别，这次就来搞清楚，再也不迷茫~
1. merge 和 rebase 的作用
-
git merge命令用于合并指定分支到当前分支
* 当前分支master, 将dev 分支合并到当前分支： git merge dev 或者 git merge dev master , 合并后master 和dev 分支都指向最新的commit, -
git rebase命令用于合并合并指定分支到当前分支 -
merge 是一个安全的操作，不会改变历史的分支树
2. 场景
有mater 和 feature 分支如下：
git merge
执行命令：
git checkout feature
git merge master
以上等价于： git merge master feature
将master上的提交合并到feature 上，此时，在feature 上回自动产生一个新的commit（merge commit），如下：
git rebase
执行如下命令：
git checkout feature
git rebase master
下面来一个更形象的图：
image.png
3. merge 和 rebase 的相同点 和不同点
相同点
- 都是用于将一个分支的更改并入另一个分支，只不过方式不同
不同点
-
合并方式
- merge master 分支的修改到 feature 分支上，会在feature 分支上产生一个新的commit 为 （merge commit）
- rebase 的本质是变基，它会修改历史的分支树，如果将 master 分支合并到 feature 上，就会把 master上的提交全部移动到 feature 分支的顶部，然后将它们的分支树变成同一条直线
- 如果rebase 过程中，想中途退出， 恢复rebase 前的代码， 可以用：
git rebase --abort
-
冲突
- rebase： 使用rebase 的冲突是一个一个解决，如果 有是个冲突，先解决第一个，然后使用命令 git add -u , git rebase --continue , 继续后才会出现第二个冲突，直到所有的冲突都解决完
- merge ： 所有的冲突是全部显示出来
4. merge 和rebase 的优缺点
- 优点
- merge 记录了真实的commit 情况，包括每个分支的详情
- merge 全部冲突一次性解决
- 变基： rebase 合并commit 历史，得到整洁的分支树
- 缺点
- merge 每次会产生一个新的commit ，污染分支
- merge 时会看到分支比较繁杂
- rebase 合并后代码出现问题，不容易定位，因为rewrite 了 history
- rebase 解决冲突要一次一次的解决
git rebase 场景分析：
上面是 rebase master 分支到feature 分支上，可以看到rebase 的原理：
rebase 时会将master 上新的commits 移动到 feature 分支的顶端, 但是其他同事还在 original master 分支上，这时候git 就会认为feature 分支的历史与其他人的master 分支有分歧，就会产生冲突。
所以在谨慎使用git rebase, 使用rebase 之前需要确定：
别人会看到这个分支吗？别人会用到这个分支吗？如果有，不能用这中破坏性修改分支历史的rebase 命令
如果没有，可以用
5. merge 和 rebase 使用场景
Rebase 的黄金法则
never use it on the public branch （不要在公共分支上使用它）
- 一般情况，合并两个分支的代码，最好还是用merge 这种没有破坏性的合并方式
- 在git pull 的时候，会用--rebase
- 要合并的分支是自己的临时分支，用 git rebase 这种干净整洁的合并方式，将合并分支树变成一条直线
如果选择？
如果合并后想要一个干净的，没有merge commit 的线性历史树，选择 git rebase如果想要保留完整的历史记录，避免重写commit history 的风险，选择 git merge
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
查看分支合并图: git log --graph pretty=online
网友评论