簡言之,編輯完衝突的檔案、用 add stage 起來後,下一步應該是 rebase --continue 才對; 但我一直是 commit,然後才 rebase --continue,大錯啊!

學習 rebase 時一直疑惑「fix conflicts and then run "git rebase --continue」裡的「fix conflicts」到底是什麼動作,最後試出來是 git commit(錯),就一直錯到現在。


示範一下 commitrebase --continue 誤用的慘狀。

  1. 我在 upstream branch。
    Log 最下面的 commit 是沒問題的,但上面兩個 commit 等下會有衝突。
    註:純 demo 方便,通常不會在 upstream 作 rebase

    upstream 的 log
  2. 另一個 branch demo,我做了一個 commit,等下 rebase 時會衝突。

    demo branch 的 log
  3. 開始 git rebase -i demo,果然衝了。

    進行 rebase,產生衝突

    出現 git 提示「fix conflicts and then run "git rebase --continue」。

  4. 手動編輯衝突的檔案(解除衝突),過程省略。

  5. git add . 把解好的部分 stage 起來,到此為止的步驟都沒有問題。

    將檔案 stage 起來,視為已手動解完衝突
  6. 錯誤的做法:git commit
    會進入編輯訊息畫面,預設訊息還會附上 Conflicts: src/vars.js

    使用 git commit 時的 commit 訊息編輯畫面

    雖然覺得奇怪(不是解了嗎?)但習慣後就不會再卡了,還會視情況把 Conflicts: 部分刪掉……

  7. git commit 的結果:

    commit 後的結果

    糟糕的事發生了,author 和 committer 都變成我了,這不能接受啊!

    git 用這麼久,怎麼可能沒發現呢?
    其實印象中有幾次 rebase 後作者變成我,覺得很怪就沒 push 出去,但發生次數很少,大概是不常收 pull request、解衝突時幾乎 author 都是自己吧。

  8. 正確做法 git rebase --continue 後的預設訊息。

    使用 git rebase --continue 時的 commit 訊息編輯畫面

    不但沒有 Conflicts:,也有顯示原作者是誰。

  9. 正確結果,committer 是我,但 author 保持不變。

    continue 後的結果