git两种合并方法 比较merge和rebase

18:01 2015/11/18
git两种合并方法 比较merge和rebase
其实很简单，就是合并后每个commit提交的id记录的顺序而已
注意：重要的是如果公司用了grrit，grrit不允许用merge，所以好像都是用rebase
却别讲解，比如：在服务器上的develop分支有多人在开发，你们同时clone或pull下来最新代码，但是开发进度不一样，你在开发一个任务的时候其他人提交了编号为1，2的commit和push，你现在开发完了也要提交，你的提交编号是3，4(注意：编号不代表顺序现实中其实是很长的随机字符串)，现在rebase是让你代码的提交到其他人的之后
讲解博客：http://blog.csdn.net/jollyjumper/article/details/24743751
推荐博客：http://blog.csdn.net/wh_19910525/article/details/7554489
开始几次没用到，所以没看懂，后来用到了，带我的人给我解释了，所以看懂了
其实以为懂了，后来带领我的人亲口讲解之后才算明白了。
需要注意的是当你clone代码（develop分支）之后，在本地clone下来的代码中又新建了自己的工作分支(git bash命令窗口)进入克隆下来的代码文件夹后 git checkout -b mywork(---这是为了随时可以接收新的新的紧急开发或bug任务，不至于开发未完成而影响接收新任务或需要其他备份处理操作，因为此时可以再从develop分支上新建新的任务工作分支：git checkout -b mywork2进行新任务开发)的时候rebase是从本地的clone下来的代码进行交互，而不是与服务器上的代码进行交互，除非特殊声明代码可和分支，(重点：所以在自己的开发分支上完成开发任务后要切换回到原来的clone分支develop：git checkout develop，然后：gi pull origin develop，然后再切换到开发分支：git checkout mywork，这时候进行rebase才会有效)我就在这里一直迷糊，后来才明白。merge应该同理。
当然，我猜应该有其他方式，就是让工作分支和服务器直接进行交互pull和push，但是那就很大程度失去了工作分支的意义了，几乎没有创建工作分支的意义了。
总算明白了