談談 Git 代碼回滾

本文講述瞭如何使用 git rebase -i 及 git cherry-pick 實現代碼回滾。代碼回滾屬於高危操做，建議慎用！

下載示例源文件

爲何會寫這樣一篇文章？實際上是有一段歷史的：在一次迭代中並行開發着 n 個需求，到提測之時各需求的代碼陸陸續續被合併到了測試分支。生活原本很平靜，但兩天後測試的頭目說「咱們組發生了點情況，本次迭代的需求在規定時間內沒法測完，但老闆又強制要求了上線時間，咱們把優先級較低的需求的代碼從測試分支抽出去吧！」。當時真是心中一萬隻 XXX 飄過...

咱們來模擬一下上述場景：迭代中並行開發着 3 個需求 feature一、feature二、feature3，在各自的開發分支上相安無事（假定測試分支爲 master）。

其中 feature2 與 feature3 須要修改同一文件，咱們故意製造了一個衝突：

提測時間到了，feature1 的代碼被合併到了測試分支：

在 feature1 修復了 1 個 bug 後，feature2 也提測了：

然後 feature3 也提測了，在合併 feature3 的代碼時，剛剛製造的衝突爆發了：

咱們須要解決衝突後再合併代碼：

在 feature3 提測後，咱們又修復了幾個 bug：

固然，feature2 雖已提測但並未進入測試，bug 的修復均是針對 feature1 與 feature3 的。

此時，feature2 的測試沒法正常進行，須要將代碼從測試分支上抽出...

以防萬一，先將 feature2 分支備份：

git checkout feature2
git checkout -b feature2-copy

咱們來查看一下 feature2-copy 分支的提交記錄：

git log

咱們須要回滾最新的 3 個提交（由於 3 個 feature 的開發分支均是從第一個提交的時間點上切出的），固然現實中針對某需求的提交毫不止 3 個。如果將提交逐一 revert 那麼工做量感人，咱們何不將 n 個 commit 合併爲一個 commit 而後一同 revert 呢？

使用 git rebase -i 來合併 commit，須要拼接回滾至的 commit 的 hashcode：

git rebase -i e08ddaf558b9ad84422db5e4b620dcab97623fde

然後出現以下對話框：

咱們須要將最新 2 次提交的 command 更改成 s：

修改後保存並退出進入以下對話框：

咱們須要修改最初一次提交的 commit message：

修改後保存並退出，再次查看 feature2-copy 分支的提交記錄：

3 次提交被成功合併，可喜可賀！接下來咱們須要 revert 被合併的提交：

git revert e544464c3de69adef5ca7556001abebaf40b218b

保存並退出，再次查看 feature2-copy 分支的提交記錄：

此時天真的我認爲將 feature2-copy 合併到測試分支便可成功抽去 feature2 的代碼，其實否則。正確的作法是使用 git cherry-pick 將 feature2-copy 分支上 revert 提交合併到測試分支上：

git checkout master
git cherry-pick b309f7944d2422d8fe647dca61bda518b192628f

此時，feature2 的代碼成功從測試分支上抽離。

最後爲你們推薦一枚 Git 圖形化客戶端：GitUp

---

做者：呆戀小喵

個人後花園：https://sunmengyuan.github.io...

個人 github：https://github.com/sunmengyuan

原文連接：https://sunmengyuan.github.io...