簡言之,編輯完衝突的檔案、用 add
stage 起來後,下一步應該是 rebase --continue
才對;
但我一直是 commit
,然後才 rebase --continue
,大錯啊!
學習 rebase 時一直疑惑「fix conflicts and then run "git rebase --continue」裡的「fix conflicts」到底是什麼動作,最後試出來是 git commit
(錯),就一直錯到現在。
封存
簡言之,編輯完衝突的檔案、用 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 保持不變。
感謝提供~自動重新整理真的慘
神奇的解法!
取得BlogId >> data:blog.blogId
不妙,我也沒留底了
大大
檔案已失聯,跪求檔案
現在 Apple Music 幾乎都找的到。
https://itun.es/tw/JeB9o
'96 年在泰國工作接觸到 carabao, 隔年亞洲金融風暴泰國重傷,大街小巷都在唱 made in Thailand ⋯