git rebase 和 git merge 總結

git merge 和 git rebase 都是用於合併分支，但兩者是存在區別的。

在使用時，記住如下兩點：

1. 當你從 remote 去 pull 的時候，永遠使用 rebase（除了一個例外）
2. 當你完成了一個功能（假定你是單獨開本地分支去作的）後打算合併到主幹分支的時候，永遠使用 merge

1、merge

　　  marge 特色：自動建立一個新的commit
　　若是合併的時候遇到衝突，僅須要修改後從新commit
　　優勢：記錄了真實的commit狀況，包括每一個分支的詳情
　　缺點：由於每次merge會自動產生一個merge commit，因此在使用一些git 的GUI tools，特別是commit比較頻繁時，看到分支很雜亂

2、rebase

　　rebase 特色：會合並以前的commit歷史
　　優勢：獲得更簡潔的項目歷史，去掉了merge commit
　　缺點：若是合併出現代碼問題不容易定位，由於re-write了history 　　合併時若是出現衝突須要按照以下步驟解決

• • 修改衝突部分
  • git add
  • git rebase --cotinue
  • （若是第三步無效能夠執行 git rebase --skip）

　　不要在git add 以後習慣性的執行 git commit命令 　　

　　The Golden Rule of Rebasing：never use it on public branches(不要在公共分支上使用)

3、總結

• • merge 是一個合併操做，會將兩個分支的修改合併在一塊兒，默認操做的狀況下會提交合並中修改的內容
  • merge 將分支合併，會自動建立一個新的 commit，會引入一個外來的合併提交
  • merge 的提交歷史忠實地記錄了實際發生過什麼，關注點在真實的提交歷史上面
  • rebase 並無進行合併操做，只是提取了當前分支的修改，將其複製在了目標分支的最新提交後面
  • rebase 是變基操做，能有效的將全部 master 上新的提交併入過來
  • rebase 的提交歷史反映了項目過程當中發生了什麼，關注點在開發過程上面

4、建議操做方式

1. 完成功能分支以後先不 merge，而是回到主幹分支去 git pull --rebase
2. 若是主幹有更新，rebase 更新的內容到功能分支來預檢一下，看看在加入了最近別人的改動以後個人功能是否依然 OK（在這個過程當中可能會有衝突處理，別怪我沒提醒哦）
3. 一切就緒以後再次 git fetch 主幹看看有沒有變更（由於在第二步的進行期間沒準又有人 push 了新的變化），有的話重複第二步，沒有則——
4. 合併功能分支到主幹而後 push，完成。