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