git 中 rebase 和merge 区别以及git团队合作流程

前言：

在网上查看了需要资料，结合之前在操作git遇到的一些问题,然后自己又做了一些测试，得出了一些个人结论，应该很多错误的理解，纯属个人观点，希望各位批评指正
先列举一下网上的内容如下:
网上的参考文章

git rebase的测试

自己做的测试(没有使用orign,只在本地一个master,一个dev分支，之前orign和maste也做过测试，效果一样)

1. 先在本地创建一个test.txt文件 提交到git，然后commit
2. git checkout -b dev，创建一个分支并且切换 在第一行添加内容 ‘dev第一次修改’ 然后add 和commit -m ‘dev’第一次修改’
3. 再次在第一行添加内容 “dev第二次修改”,然后add 和commit -m “dev第二次修改”
4. 切换回master分支，添加内容“master第一次修改”,并且commit -m “master第一次修改”
5. 再次添加内容:”master第二次修改”,并且commit -m “maseter第二次修改”；
6. 这时候，master分支上 git log是 master 第二次修改，master第一次修改。 dev分支git log 查看是 dev 第二次修改，dev第一次修改

这时候，master提交了两次,dev也提交两次，类似于我们工作中，线上超前两次
这时候，我们需要做的就是这两次的冲突的解决.有两种办法，一种是rebase , 一种是merge， 我们切换回dev 分支上，执行 git rebase master ,这时候，会有冲突，我们会发现是master第二次修改这个版本和dev第一次修改这个时候的冲突, 解决完我们add 文件后再git rebase –continue,这一次是刚才解决完冲突的版本和dev第二次修改这个版本的冲突，add文件后再次continue，才会解决完所有的冲突。这时候

在dev分支 git log 上看到的是如图

git log –graph –pretty=oneline –abbrev-commit查看树形图

使用 git log -p text.txt查看内容

git merge测试

大家都懂，就不在这写测试结果了，大家可以按照上面git rebase相似的方式去测试

git rebase 和 git merge图解

网上找的两张图，这两张图参考文文章

merge就会再多生成一个节点

git rebase 和 git merge 优缺点小结

其实总结这么多， 我觉得二者都各有优点 ，是我自己的想法:
1. 网上都说git rebase看起来就像是一条分支，看起来很干净，舒服一些吧
2. 个人感觉git rebase确实很好用，追溯历史也是很好的（可能这句话有些问题）,然而某些情况下， merge也很好用，merge追溯历史可以清楚的知道，哪个人在哪里做了什么事，rebase在追溯历史的时候，不太清楚那个人在哪里做了什么事，但是在版本回退时比较好，可以准确的回退，出问题的时候比较好解决。
3. rebase还可以将不同的分支合并，使用git rebase -i也可以合并多个commit，参考文章
4. merge合并分支比较简单粗暴，不像rebase那么复杂
5. rebase会影响到其他人的历史，merge可以准确的回到某个节点合并之前

git rebase 和 gitmerge应用场景

纯属个人理解:
1. rebase可以用来合并多个commit，不过我觉得作为一名开发人员，最好别合并master分支(origin分支)上的commit, 除非是领导，觉得commit数目太多，可以合并一些
2. 自己一个master分支，是从orign pull下来的，我们如果针对master创建一个个人分支，例如叫dev分支，在dev分支上有多个commit的时候，你又不想多个commit太乱，这时候你可以在分支上 合并commit。（真心不建议在dev分支上做多个commit，如果必须得做多个commit，又不想rebase continue多次的，解决多次冲突的麻烦，就使用merge）
3. merge和rebase一样都能实现分支的合并，在分支合并过程中，最好选择一种方式，要么merge，要么rebase

git多人合作的流程

针对于merge合并分支的流程

1. 做几个假设:线上只有一条origin。
2. 张三, 李四，王五都从origin上clone一个master分支
3. 张三在本地master分支上，创建一个zhangsan分支
4. 张三在zhangan分支上进行工作.工作完成后，切换到master分支
5. 假如这时候origin分支上可能已经被李四或者wa王五提交了多个版本，假如有4个版本了，张三在master分支上pull一下，这时候肯定没有冲突
6. 张三在master分支上，git merge zhangsan, 解决完冲突， 然后将master， push上去,这时候张三任务完成，这时候张三如果想继续在zhangsan分支上开发，直接在zhangsan分支上，让指针指向master的最顶端的commit即可

针对rebase合并分支的流程

1. 做几个假设:线上只有一条origin
2. 张三, 李四，王五都从origin上clone一个master分支
3. 张三在本地master分支上，创建一个zhangsan分支
4. 张三在zhangan分支上进行工作.工作完成后，切换到master分支
5. 假如这时候origin分支上可能已经被李四或者wa王五提交了多个版本，假如有4个版本了，张三在master分支上pull一下，这时候肯定没有冲突， pull之后，切换会zhangsan分支
6. 张三在zhangsan分支上，git rebase master, 这时候可能有多个冲突(zhangsan分支commit过几次，就会有几次冲突)， 然后 一直continue，直到解决完冲突为止。
7. 然后切换回master， 在master分支上，指针指向zhangsan分支的顶端（操作方法 git reset –hard zhangsan顶端的commit值）,然后push master上 远程仓库 这时候张三任务完成