簡言之,編輯完衝突的檔案、用 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
不妙,我也沒留底了
大大
檔案已失聯,跪求檔案
Yeah it really works but its better to keep a towel or any kind of cloth below the stained cloth nor the stain will be absorbed by the other side of that cloth.And it really doesn't matter whether the stain is of 1 week or 1 month.
Alec is awesome! I fix nearly everything that I possibly can in my home and use youtube almost exclusively. Most posts are a constant ramble and yammering and words filling dead air space. It 's unnecessary and confusing. Alec speaks only when necessary and demonstrates each fix quickly and accurately. Camera person is completely tuned in to every move Alec makes. Thanks! Just spot on