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，但是那就很大程度失去了工作分支的意義了，幾乎沒有建立工作分支的意義了。

總算明白了