開發過程中，我們經常會遇到代碼回滾的情況。正常人都知道，git 回滾有兩大寶：

• git revert
• git reset

當我們在本地開發，還未 git push 到遠端時，可以毫無顧忌的使用 git reset 進行回滾。更多的情況中，我們不僅 push 了，而且由于開發周期長，在開發過程中不斷的 merge master 和 merge other-branch 以發布到預發環境測試或者多需求合并測試。

突然

上線后用戶投訴，需要馬上下線本次需求中的 A、B、C，只保留 D、E、F，迅速回滾，不要影響更多用戶。

撕逼？那肯定是來不及了。一群人在你背后眼巴巴地盯著你，就問你慌不慌...

接下來，我們來說說，如何在緊急回滾面前，鎮定(假)自若(裝)地進行 git 操作

簡單場景

本地操作使用 git reset 隨便玩玩就行了，我們主要講講 git revert

回滾“單一提交”

回滾“連續提交”

回滾一次“合并”

回滾合并時，如果直接使用 git revert mergeCommit 實際上是遞歸回滾里面的每一個節點，指定 -m 是指定以哪一個分支為主線，當前所在分支為 1，依次類推（一次合并多個分支時會 > 2，正常只有 1 和 2）

高級場景

如果我們遇到的問題都像上面一樣，那怎么能體現一個程序員的價值?

回滾“混合場景”

如以下場景中，我們期望回歸的節點之間含有一次合并導致我們無法一次回滾到位。有兩種方式：

1. 按順序見招拆招回滾（三次操作）

2. 先回滾 D + F，再回滾合并（兩次操作）

【推薦】使用方案1，按順序回滾會處理更少的 conflict，否則假設 D、F 是一系列提交合集，那么回滾成本很高

回滾有點復雜“混合場景”

如下的場景中，特殊的地方在于，我有一個 feature，搭車了一個 bugfix，我需要回滾需求但不回滾 bug

這種情況下，有兩種選擇：

回滾 G，通過 git 引一步一步回滾 F-F'-E‘-D'-C‘-E'‘(不滾)-D'‘(不滾)-C'‘(不滾) ，回滾 E+D 【推薦】回滾 G，回滾 F 丟棄 F'，回滾 D+E，復原 C‘'..E‘' 比第一種方案更快更簡單，不用處理第一種方案中的 conflict

git revert G
git revert F -m 1
git revert D..E
git cherry-pick C``
git cherry-pick D``
git cherry-pick E``

回滾復雜的”混合場景“

標注解釋

• 藍色代表已經合并到遠程分支 Master 生成了 tag
• 紅色代表需要回滾的 commit
• 綠色代表正常 commit

場景解釋 一開始你所在的團隊接到一個需求，這個需求中可以分拆出一個自需求，最終可以實現兩人并行開發

• 兩個人 Pa 和 Pb 分別在 Master 基礎上創建了新分支
• 在開發過程中 Master 上發布了兩次 bugfix（v2、v3）
• 由于需要在預發上持續測試，所以 Pa 主動合并了 Master
• Pb 在自己分支 B‘ C' D‘ 中廢棄了之前的舊邏輯和一些代碼的小幅重構（穩定性更新），之后 一直在本地開發新功能 驗證
• 最后即將上線時需要合并自需求一起驗證，驗證后 Pb 發布了 v3
• 后續又經過了一次 bugfix 發布了 v4
• 結果，產品反悔了 WTF ？？？
• 最后，要廢棄新功能，需要重新設計產品，但是舊有邏輯仍然按原計劃廢棄 >> F(v2) + B'-D'

回滾方式

遇到這樣的場景，一般有如下幾種方案回滾：

• 回到最新的遠端 Master (v4) 手動識別需求代碼進行人工刪除 刪除自己的代碼還好，刪除別人的代碼就有點難度了，而且當提交量很大時很耗時耗力
• 復制 F(v2) 替換 Master(v4)，手動或應用 B'-D‘ commit 圖示情況，直接復制粘貼是個便捷的方法，再次回復 B'-D' 也費不了多大事，只是手動操作難免失誤，尤其是增加/刪除文件的情況，復制粘貼容易出錯
• 【推薦】按時序回滾（O'-T‘、L'‘、F'‘-K'‘^、B'‘-C'‘、E'-N‘） 版本控制本來就是為了代碼管理更便捷，使用 git 操作后面的人不僅能看懂回滾了哪些 / 如何回滾的 / 怎么處理回滾中的 conflict 的，如果回滾錯了還可以回滾“回滾了的”操作

git revert N`..S`
// 僅回滾非 merge Master 節點，保留 Master 代碼
git log B``^..L`` --first-parent --no-merges --pretty=format:%H | xargs | xargs git cherry-pick -n 
git revert E`..F`

最后多說一點

想要回滾不頭痛，提前就要做好功課并且保持清晰的提交記錄，否則幾百個 commit 回滾起來就變成了一場災難。提幾個好方法

保持 Commit 清晰

• 一次 commit 的做一件完整的事，不要摻雜別的需求和 bugfix，未完成需求前不要輕易提交編譯代碼；
• commit 有清晰的描述

善用 rebase

• 如果有幾次 commit 干的是一件事，可以通過 rebase 合并，不要出現很多 init、update 之類的無效 log
• 剛剛提交代碼后，又想起來某個配置需要改個版本，可以先 commit，最后使用 rebase 清理一下版本樹

多人并行開發，創建獨立的分支進行合并測試 不要合并到某一個分支中，防止上線時間變化導致代碼再次清洗

到此這篇關于如何使用Git優雅的回滾實現的文章就介紹到這了,更多相關Git 回滾內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！