僅記錄一下今天合并時出現的故障，大概有個認識和猜測，還未完全搞清楚其中機理。
前提
幾天前， 0.8d和1.0兩個分支同時從dev上開出來。現在，0.8d已經merge到dev（大概有30多個commit）
欲進行的操作
將dev合并到1.0上（目的：將0.8d上的代碼體現到1.0分支上）
故障步驟再現
- git checkout 1.0
- git merge dev （此時出現大量沖突）
- （解決沖突）git add . && git commit -m 'xxx'
- git pull （此步出現問題，截圖如下。經驗：下次若不小心又執行了此命令，趕緊STOP!!：git rebase --abort）
git-pull.jpg
git-status.jpg
為了“解決問題”，匆忙中，不得不反復執行下面動作序列：
- git pull （然后提示有沖突）
- 解決沖突，git add .
- git rebase —skip
（旁白：git pull一般來說是commit之后、push之前的一個下意識動作，在這里卻導致了問題。因為我們的git pull是基于rebase模式的，故這里pull又會進行一番rebase的操作。至于為何這個merge之后的結果再rebase會出問題，我暫時不甚了了。）
正確的解決方法
不執行第4步，直接push（也就是說避免執行那個rebase），即：
- git checkout 1.0
- git merge dev （此時出現大量沖突）
- （解決沖突）git add . && git commit -m 'xxx'
- git push
以下內容不要看，是我考察的中間過程
不要看，不要看
另外一種可行的方法：dev rebase 1.0
具體步驟如下：
- git checkout dev
- git rebase 1.0 （這樣出現的沖突只有2個文件）
- git checkout 1.0
- git merge dev
原因：為何這樣就少沖突了？我想起hh說了，他是在0.8d上執行過git pull origin 1.0（本次merge之前兩個分支上就已出現了好多相同的commit，而這是一次非預期的誤操作吧？），也就是說0.8d實際rebase過1.0。故，現在繼續之前的rebase，就是正確的姿勢。而反過來，讓1.0 rebase 0.8d則會做一些重復的工作。
經驗：
- 如果rebase時（merge同理？不確定）出現的沖突過多，可以嘗試反過來試試看如何，即：
若 A rebase B沖突過多，則可試下 B rebase A（先checkout到B上） - 只要git pull就夠了，不要git pull origin xxx ?。?/strong>。后面兩個參數缺省就是origin和當前分支。如果帶上，則可能因疏忽pull別的分支（如這次的情況）
