簡言之，編輯完衝突的檔案、用 add stage 起來後，下一步應該是 rebase --continue 才對；
但我一直是 commit，然後才 rebase --continue，大錯啊！
學習 rebase 時一直疑惑「fix conflicts and then run "git rebase --continue」裡的「fix conflicts」到底是什麼動作，最後試出來是 git commit（錯），就一直錯到現在。
示範一下 commit 和 rebase --continue 誤用的慘狀。
-
我在 upstream branch。
Log 最下面的 commit 是沒問題的，但上面兩個 commit 等下會有衝突。
註：純 demo 方便，通常不會在 upstream 作 rebase
-
另一個 branch demo，我做了一個 commit，等下 rebase 時會衝突。
-
開始
git rebase -i demo，果然衝了。
出現 git 提示「fix conflicts and then run "git rebase --continue」。
-
手動編輯衝突的檔案（解除衝突），過程省略。
-
git add .把解好的部分 stage 起來，到此為止的步驟都沒有問題。
-
錯誤的做法：
git commit
會進入編輯訊息畫面，預設訊息還會附上Conflicts: src/vars.js，
雖然覺得奇怪（不是解了嗎？）但習慣後就不會再卡了，還會視情況把
Conflicts:部分刪掉…… -
git commit的結果：
糟糕的事發生了，author 和 committer 都變成我了，這不能接受啊！
git 用這麼久，怎麼可能沒發現呢？
其實印象中有幾次 rebase 後作者變成我，覺得很怪就沒 push 出去，但發生次數很少，大概是不常收 pull request、解衝突時幾乎 author 都是自己吧。 -
正確做法
git rebase --continue後的預設訊息。
不但沒有
Conflicts:，也有顯示原作者是誰。 -
正確結果，committer 是我，但 author 保持不變。
電梯向下