仅记录一下今天合并时出现的故障，大概有个认识和猜测，还未完全搞清楚其中机理。
前提
几天前， 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 ！！。后面两个参数缺省就是origin和当前分支。如果带上，则可能因疏忽pull别的分支（如这次的情况）
