Git 版本控制系統(3) 還沒 push 前可以做的事

這一集要講的是:還沒 push 前可以做的事,也就是 reset 跟 rebase。

相較於 SVN 這種 commit 就是送到遠端伺服器,Git 的 commit 其實東西都還是在本地端,所以只要你還沒 push 出去分享給別人,你的 commit logs 是可以修改的!! 這種功能非常的 powerful,可以讓你 undo 和 rewrite commit history。如果你用 Git 只會 git commit 然後接著馬上 git push,那你就沒有學到精隨啊!~

使用告誡:如果你已經 push 出去了,請千萬不要做 rewrite history 的動作,會天下大亂啊。正確善用 undo changes/rewrite history 的功能,我們可以讓東西準備好弄的整整齊齊才 push 出去給別人 pull。

讓我們來學幾招吧:

amend

git commit -C HEAD -a –amend 快速修正前一次 commit 的錯誤,只要修 typo 之後打這行,就會替換掉前一次的 commit

reset

git reset 砍掉 commit 重來,但是修改的程式還是留在 working tree。例如:

git reset HEAD^ 就會回到前一版本(一個^表示是前一版),並把其中的 changes 繼續留在 working tree 中。適合發現前一次 commit 有問題或是想要修改 commit log,可以修改後再重新 commit。

git reset 如果加上 –soft 參數則會把 changes 直接加到 staging area。

加上 –hard 參數表示不留 staging area 也不留 working tree(完全刪除任何修改記錄),例如:

git reset –hard HEAD^ 則會完全抹掉前一次的 commit。

另個常用的情境是要把修改的檔案從 staging area 移走,指令就是 git reset HEAD filename (但還是留在working tree)。BTW,要回復 working tree 中修改的檔案成本來的樣子,指令是 git checkout filename (重新拿出本來的檔案)

順道一提,如果東西已經 push 出來了,要怎麼回復? 這時候就得用 revert 了。

git revert 會用一個新的 commit 來回復所有的變更(適合已經push出去給別人的情境)。加上 -n 可以不先 commit,這樣可以多 revert 幾次後再一次 commit。

指令會有差別都是因為 remote repo.<-> local repo.<->staging area<->working tree 分了四層移來移去的關係,你只要想清楚這幾層就融會貫通了 (請參考第一集有解釋 staging area 和 working tree)。

rebase

我在 使用 rebase 避免無謂的 merge 一文中有解釋過 rebase 的其中一個用途。而 rebase 的真正潛力是,我們可以從指定的版號之後,重新隨你意 commit 一次來重建 history,超威的。首先輸入 git rebase -i 版號 就會可以跳出 editor 可以編輯,我們可以

a. 變更 commit 順序
b. 將多個 commit 合併 squash
c. 將一個 commit 打散 (edit 會停著讓你可以 git reset HEAD^ 打散重新 commit,完成後 git rebase –continue )

另一種 rebase 用法是不需要打 -i ,直接指定另一個 branch 或 tag,這樣就會重新 commit 另一個 branch 的東西,然後才 commit 自己的 (也就是 使用 rebase 避免無謂的 merge 的用法)。

git rebase 若有 conflict 就會停下來, 跟 merge 一樣處理完 add,然後 git rebase –continue 就會繼續 commit (也可以 –skip 或 –abort 放棄啦)

rebase 有個 onto 參數用法,使用的情境是:假設你有三個有 dependency 的 branch 分別叫做 master/contact/search,後來發現 search branch 只有 depend on matser,於是你可以輸入 git rebase –onto master contact search 這樣就會讓 search branch 從 master 的地方開始重新 commit。

再次提醒,rebase 千萬只能適合東西還沒 push 的情境,或是你自己的 local 專用私人 branch。rebase 一個已經 push 出去的 repository,然後你又把修改的 history push 出去,是會造成超級大災難的。

在學習 rebase 的過程中,很容易拿來跟 merge 比較一下。我發現一個有趣的不同點:如果有檔案在要被 merged 的 branch 中被刪除,如果用 rebase 檔案最後會不存在,但是用 merge 的話檔案最後還在 XDXD

另外,在 rebase branch 之後,如果再做 merge,就會發現因為 master 直接就是被 merge 的祖先,所以線圖直接變成一條線,而有這種 parent 關係的 merge 就叫做 fast-forward。換句話說,因為沒有發生任何 merge commit,也不會發生 conflict,Git 內部單純只是變更 reference 參照,所以謂之 fast-forward。

好心提醒,因為開 local branch 是如此便宜無害,所以要做 rebase 時建議您可以先開一個 local branch 來實驗 rebase。老實說,rebase 還挺危險的 XDXD

最後,rebase 我認為算是 Git 初學者最難理解的功能吧,但是如果不知道什麼是 rebase,就不能說是懂 Git 啊。

參與討論

8 則留言

  1. 自動引用通知: Git (VCS) | 阿倫基's free DNA
  2. 自動引用通知: Git Rebase « Yiming Zhang
  3. 版主你好,小弟有些問題想請教

    文中有一段:「再次提醒,rebase 千萬只能適合東西還沒 push 的情境,或是你自己的 local 專用私人 branch。rebase 一個已經 push 出去的 repository,然後你又把修改的 history push 出去,是會造成超級大災難的。」

    這個前提是,使用 Git 時有別人也在使用你的 branch 才會發生災難吧,如果準備 rebase 的 branch 只有自己在上面開發,針對遠端進行 rebase 應該是可以的…吧?還是有哪些地方我沒有考慮到,希望版主指點迷津

發佈留言

發表迴響