開發過程中，我們經常會遇到**回滾的情況。正常人都知道，git 回滾有兩大寶：
當我們在本地開發，還未git push到遠端時，可以毫無顧忌的使用git reset進行回滾。更多的情況中，我們不僅 push 了，而且由於開發周期長，在開發過程中不斷的merge master和merge other-branch以發布到預發環境測試或者多需求合併測試。
突然上線後使用者投訴，需要馬上下線本次需求中的 a、b、c，只保留 d、e、f，迅速回滾，不要影響更多使用者。
撕逼？那肯定是來不及了。一群人在你背後眼巴巴地盯著你，就問你慌不慌...
接下來，我們來說說，如何在緊急回滾面前，鎮定(假)自若(裝)地進行 git 操作
簡單場景
本地操作使用git reset隨便玩玩就行了，我們主要講講git revert
回滾「單一提交」
回滾「連續提交」
回滾一次「合併」
回滾合併時，如果直接使用git revert mergecom實際上是遞迴回滾裡面的每乙個節點，指定-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``
回滾複雜的」混合場景「
標註解釋
場景解釋一開始你所在的團隊接到乙個需求，這個需求中可以分拆出乙個自需求，最終可以實現兩人並行開發
回滾方式
遇到這樣的場景，一般有如下幾種方案回滾：
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 清晰
善用 rebase
多人並行開發，建立獨立的分支進行合併測試不要合併到某乙個分支中，防止上線時間變化導致**再次清洗
git如何回滾遠端倉庫
使用git管理專案開發的過程中經常會碰到這種情況 某次提交已經push到了遠端倉庫，可是突然意識到 天哪，我怎麼做了這麼蠢的事情 那麼問題來了，怎麼將遠端 庫回滾呢？在網上看到大部分人給出的解決方案是先將本地回滾，然後刪除遠端分支，之後再將本地的分支push到遠端倉庫，這其實是一種很危險的方案，畢竟...
git的回滾操作
回滾其中的某個 commit 場景 你已經執行了 git push,把你的修改傳送到了遠端，但是這些 commit 中其中乙個是有問題的，你需要回滾那乙個 commit.方法 git revert 原理 git revert 會產生乙個新的 commit，它和指定 sha 對應的 commit 是相...
git 如何回滾遠端倉庫版本
前言 使用git管理專案開發的過程中經常會碰到這種情況 某次提交已經push到了遠端倉庫，可是突然需要回退 怎麼將遠端 庫回滾呢？不推薦這樣做 在網上看到大部分人給出的解決方案是先將本地回滾，然後刪除遠端分支，之後再將本地的分支push到遠端倉庫，這其實是一種很危險的方案，畢竟直接刪除遠端分支太危險...