在版本迭代開發過程中，相信很多人都會有過錯誤提交的時候（至少良許有過幾次這樣的體驗）。這種情況下，菜鳥程式設計師可能就會虎驅一震，緊張得不知所措。而資深程式設計師就會微微一笑，摸一摸鋥亮的腦門，然後默默的進行版本回退。
對於版本的回退，我們經常會用到兩個命令：
git reset
git revert
那這兩個命令有何區別呢？先不急，我們後文詳細介紹。
假如我們的系統現在有如下幾個提交：
其中：a 和 b 是正常提交，而 c 和 d 是錯誤提交。現在，我們想把 c 和 d 回退掉。而此時，head 指標指向 d 提交（5lk4er）。我們只需將 head 指標移動到 b 提交（a0fvf8），就可以達到目的。
只要有 git 基礎的朋友，一定會想到 git reset 命令。完整命令如下：
git reset --hard a0fvf8
命令執行之後，head 指標就會移動到 b 提交下，如下圖示：
而這個時候，遠端倉庫的 head 指標依然不變，仍在 d 提交上。所以，如果直接使用 git push 命令的話，將無法將更改推到遠端倉庫。此時，只能使用 -f 選項將提交強制推到遠端倉庫：
git push -f
採用這種方式回退**的弊端顯而易見，那就是會使 head 指標往回移動，從而會失去之後的提交資訊。將來如果突然發現，c 和 d 是多麼絕妙的想法，可它們已經早就消失在歷史的長河裡了。
而且，有些公司（比如良許的公司）明令禁止使用 git reset 命令去回退**，原因與上述一樣。所以，我們需要找到乙個命令，既可以回退**，又可以儲存錯誤的提交。這時，git revert 命令就派上用場了。
git revert的作用通過反做建立乙個新的版本，這個版本的內容與我們要回退到的目標版本一樣，但是head指標是指向這個新生成的版本，而不是目標版本。
使用 git revert 命令來實現上述例子的話，我們可以這樣做：先 revert d，再 revert c （有多個提交需要回退的話需要由新到舊進行 revert）：
git revert 5lk4er
git revert 76sdeb
這裡會生成兩個新有提交：d』 和 c』，如下圖示：
這裡只有兩個提交需要 revert，我們可以乙個個回退。但如果有幾十個呢？乙個個回退肯定效率太低而且容易出錯。我們可以使用以下方法進行批量回退：
git revert older_commit^…newer_commit
這時，錯誤的提交 c 和 d 依然保留，將來進行甩鍋的時候也有依可循。而且，這樣操作的話 head 指標是往後移動的，可以直接使用 git push 命令推送到遠端倉庫裡。而這種做法，正是企業所鼓勵的。
我們再舉個更難一點的例子。
假如現在有三個提交，但很不巧的是，那個錯誤的提交剛好位於中間。如下圖示：
這時，直接使用 git reset 命令將 head 指標重置到 a 提交顯然是不行的，因為 c 提交是正確的，需要保留的。先把 c 提交 及 b 提交全部回退，再使用 cherry-pick 命令將 c 提交重新再生成乙個新的提交 c』』，這樣就實現了將 b提交回退的需求。完整的過程如下：
通過以上對比可以發現，git reset 與 git revert 最大的差別就在於，git reset 會失去後面的提交，而 git revert 是通過反做的方式重新建立乙個新的提交，而保留原有的提交。在企業裡，應盡量使用 git revert 命令，能不用 git reset 命令盡量不用。
[1]
GitHub版本回退
git add readme.txt git commit m 描述 git log 檢視提交歷史，以便確定要回退到哪個版本 git diff 檢視尚未暫存的檔案更新了哪些部分，不加引數直接輸入 此命令比較的是工作目錄 working tree 和暫存區域快照 index 之間的差異 也就是修改之後...
git常用指令 github版本回退 reset
1 git reset mixed 此為預設方式，不帶任何引數的git reset，即時這種方式，它回退到某個版本，只保留原始碼，回退commit和index資訊 2 git reset soft 回退到某個版本，只回退了commit的資訊，不會恢復到index file一級。如果還要提交，直接co...
Git版本回退
1 檢視檔案修改歷史 git log 返回的是commit後的操作記錄 git log pretty oneline 也可以使用這個命令格式化日誌輸出 2 版本回退 git reset hard head 回退到上乙個版本 git reset hard head 100 會退到第100個版本，例如現...