作为几年的开发者，会用merge但是不很清楚和rebase的区别,有点尴尬，今天查了一下资料，大概了解了一下，现在详细讲解一下这两者用法以及区别。
初始化Git文件
master merge
分支2 和master
现在在master分支上执行
Git merge 2
Yong:git_02 Yong$ git merge 2
Auto-merging 1.txt
CONFLICT (content): Merge conflict in 1.txt
Automatic merge failed; fix conflicts and then commit the result.
Yong:git_02 Yong$
报错了，因为我们修改的是同一个文件的相同位置，所以会冲突。
我们修改好这个冲突文件，冲突文件是：
冲突文件
下图是打开文件冲突内容：
冲突内容
上边是
HEAD分支的内容，=====下边是2分支的内容，项目中根据实际情况作出取舍。修改成：
修改
修改完之后进行提交：
Yong:git_02 Yong$ git add .
Yong:git_02 Yong$ git commit -a -m 'fix conflict'
[master b02486a] fix conflict
Yong:git_02 Yong$
提交后分支记录为：
image.png
然后我们切换成
checkout 2查看内容，
分支2内容
对，没看错，分支2还是原来的内容。那小伙伴该有什么疑问呢？刚才我们合并产生冲突了，而且冲突已经修复了，修复之后的内容是
5，那么为什么branch 2内容没变呢？因为我们是在master上merge的，分支2合并到了master，master上有master和分支2的内容，但是分支2的代码没变。我们在看一下 master的内容：
master
所以我们多人合作开发的时候，产生冲突了，然后又用merge合并了分支，把冲突改好了最后也提交了，下一个任务来的时候，还是基于自己的老分支开发，等任务结束的时候，合并分支发现？怎么冲突还在？解决这个问题的 话，每次新的任务都从稳定的
devnew 一个分支出来，在新的分支开发任务，这样子，每次切出来的分支都是一个新的分支，而且是有同事提交的代码的。不会之前的冲突，下次提交的时候也冲突第二次。
或者旧的任务完成了，分支2 要git pull origin master，保持自己分支是最新的内容。
那么我们现在将分支2的内容改成
1234
5
然后在master分支上
git merge 2
冲突了：
冲突
打开冲突看一下，原来第一次合并冲突在分支2中的内容并没有修改，然后新增了一行5，导致旧版本
1234和5都冲突了。
冲突
master rebase
image.png
冲突节点
修改成：
image.png
然后执行：
git rebase --continue
第二次冲突：
第二次冲突
冲突修改完成了，结果如图：
结果
解决完冲突：
解决完冲突
然后我们在分支branch2上修改文件：
旧版：
初始化Git文件
旧版和新版对比：
所有节点在一条线上，说明合并到了一个分支上，重合的节点内容是一致的。branch2上的内容还是旧版内容，开发新的任务需要从新pull或者 从dev新切除分支来解决内容不同步问题。
然后从branch2作出修改：
然后在其中branch2分支上 修改，提交，生成一个新的节点，从master上出来的。
branch2修改
然后在
rebase的基础上进行merge操作，差异很明显。
rebase and merge
$ git log --graph --pretty=oneline --abbrev-commit
* d6ce4b2 (HEAD -> master) merge from 2
|\
| * 9e7c360 (2) 1.txt add line
* | 206cfd1 add6
* | e67db5a 1_m
|/
* 91052c8 4
* a8331c2 3
* 680986b 2
* e6a896f 1.txt
其实rebae就是按照时间线的前后顺序进行合并，a分支和b分支，
a rebase b，b的最后一个节点分别和a节点进行对比和合并。a和b合并成一条线。
a merge b只是a分支和b分支最后一个提交节点进行对比合并，中间的节点不进行对比和合并。所以合并结果是2条线。
参考资料：
网友评论