懂git的麻烦看一下，merge和rebase的区别就只是commit顺序不一样，最终合并结果都是一样的是吗？

Question

网上看了些git merge和git rebase的区别，好像就只是commit顺序不一样（就是那种合并的曲线），结果貌似没有区别，还有就是解决冲突的次数不一样，但该冲突的还是会冲突，这两者还有什么别的区别吗？

还有一个问题是关于git fetch的，这个指令主要是用于远程分支和本地分支的合并是吧，比如git pull就等于是git fetch ＋ git merge。
那如果我没有远程分支，全都是本地分支，那本地分支与本地分支之间的合并，是不是不用fetch，直接merge或者rebase就可以了是吧？

本人刚用git，就怕自己把公司的代码库给搞坏了，那就太丢人了，所以现在git提交合并什么的都畏手畏脚，碰到冲突就慌的不行

Answer 1

...这两者还有什么别的区别吗？

简单来说，git merge 是在合并两个分支时，新建一个新的 merge commit（你可以理解为两条河流汇合成一条），而 git rebase 则是将一批 commits 重新在另一个 commit 点的基础上“重演”了一遍，且重演之后的 commit 实际上是全新的。

可能有点抽象，可以看下这篇文章：http://www.jianshu.com/p/f23f...

那如果我没有远程分支，全都是本地分支，那本地分支与本地分支之间的合并，是不是不用fetch，直接merge或者rebase就可以了是吧？

是的。直接用 merge/rebase 即可。

Answer 2

一个帖子只问一个问题。rebase和merge的区别只是commit的顺序问题。如果你的commit是按照时间顺序，那么rebase和merge就没有任何区别了。

你可以认为rebase的作用是修剪枝杈，merge只是按照操作顺序进行合并代码，不按时间顺序的commit只能作为分支嫁接到主干上。rebase就是把这些枝杈剪下来，按照时间重排之后重新嫁接到主干上，因此被rebase修剪过的commit会非常好看，在分支图上看到的是一条直线。缺点就是你的merge不按时间顺序来的太多，会导致以前解决过的冲突全部重新解决一次，非常痛苦，因此选用rebase还是merge团队一开始就必须规定好，否则后期调整很麻烦。

就我个人而言平时喜欢用rebase，我个人开发的项目基本都是rebase的，分支图好看。团队开发大多人还是习惯用merge的。

git pull = git fetch + git merge，因此你完全可以手工fetch然后merge实现完全等同的功能。

git pull --rebase = git fetch + get rebase

Answer 3

• git merge 用于合并分支
• git rebase 用于合并commit
• git fetch 用于更新所有分支状态，如远程仓库已添加一个分支，可通过git fetch -p将新分支拉取下来
• git pull 用于取回远程主机分支的更新
• git pull不等于git fetch ＋ git merge
• 本地分支的合并是用git merge命令
• 推送本地分支到远程git push -u origin barnch_name

---

建议参考：

• Git 使用规范流程
• Git远程操作详解