工作中會遇到這樣的情況，提交的代碼造成了其它的bug，但是此間你已經又提交過多次了，所以需要回退到一個沒有出現該bug，但下一個版本出現該bug的版本，進而可以找到因爲提交了什麼導致了該bug。
git 的版本回退功能非常重要，下面我將一步一步的解釋如何實現版本回退。（關於對 git 中工作區、暫存區、本地倉庫、遠端倉庫、如何將暫存區的改動“添加”以及“提交”到本地倉庫、添加遠端倉庫、配置 git 的個人信息、添加 ssh-key 等不熟悉的，可以看我博客裏的【Git】分類，這裏不再贅述）
首先你需要有一個與遠端倉庫關聯的本地倉庫，這裏我在工作區新建一個 VersionFallback.txt ，
一：本地文件推送到遠端
第一次提交
增加內容 日期：2019年8月15號 工作內容： 定義了與服務器間的消息號。
然後將本地改動添加，提交到暫存區，最後推送到遠端倉庫，如下圖所示
同理
第二次提交 增加內容 日期：2019年8月16號 工作內容：佈局UI。 記錄爲版本二
第三次提交 增加內容 日期：2019年8月17號 工作內容： 實現生成撲克牌的邏輯。 記錄爲版本三
最終本地文件的內容如下圖所示
二：顯示提交日誌
使用 git log 指令，顯示從 最近到最遠 的提交日誌，我們可以看到有3次提交
如果覺得輸出信息太多，可以使用指令git log --pretty=oneline (一行一行顯示提交日誌)
注意事項一：pretty 前面是兩個 - 。
注意事項二：是 oneline，不是 online，一行一行顯示，不要少了字母。
上圖中的一串類似 1e943…4523 的是 commit id（版本號），和 SVN 不一樣，Git 的 commit id 不是 1，2，3……遞增的數字，而是一個 SHA1 計算出來的一個非常大的數字，用十六進制表示。你的 commit id 和我的肯定不一樣，以自己的爲準。
爲什麼 commit id 需要用這麼一大串數字表示呢？因爲Git是分佈式的版本控制系統，如果多人在同一個版本庫裏工作，大家都用1，2，3……作爲版本號，那肯定就衝突了。
三：版本回退操作
首先，Git 必須知道當前版本是哪個版本，在 Git 中，用 HEAD 表示當前版本，也就是最新的提交 1e943…4523（注意我的提交id 和你的肯定不一樣）。
版本回退操作有兩種方式，一種是從後往前(回退到當前版本之前)，一種是從前往後(回退到當前版本之後)。
<1>回退到當前版本之前：git reset --hard HEAD^
解釋：一個 ^ 表示回退到上一個版本，即 HEAD^ ，兩個 ^ 表示回退到上上一個版本，即 HEAD^^，當然，回退到第100個版本，肯定不會寫100個 ^ ，我們這樣簡寫爲 git reset –-hard HEAD~100 。
現在我們使用該指令，把當前版本（版本三）回到到上一個版本（版本二）
由圖，現在的 HEAD 指針指向了 90a8d76，即版本二的 commit id，此時你再打開該文件，果然被還原了。
當然，還可以繼續回退到版本一，不過我們先通過 git log 指令查看一下當前版本庫的狀態
我們發現，最新的版本三已經看不到了，但我們想回到版本三怎麼做呢，那就是第二種版本回退的方式
<2>回退到當前版本之後：git reset --hard 版本號
版本號沒必要寫全，當然也不能只寫前一兩位，因爲 Git 可能會找到多個版本號，就無法確定是哪一個了，一般我們取其前 8位，Git 會自動去找。
現在我們使用該指令，把當前版本（版本二）回退到下一個版本（版本三）
此時你再打開文件，發現文件又回來了。
也許有人會問了，我從版本三回退到版本二時，把命令窗口給關閉了，使用 git log 看不到版本三的版本號，是不是就回退不回來了？答案是當然不會。
Git 提供了一個git reflog 命令用來記錄你的每一次命令。
從這裏我們可以看到版本三的版本號是 1e943ce 。
當然，假設你現在在版本三，想回退到版本二，不是一定要用 git reset --hard HEAD^ ，用 git reset --hard 90a8d76 也是可以達到回退的效果的。
Git 的版本回退速度非常快，因爲 Git 在內部有個指向當前版本的 HEAD 指針，當你回退版本的時候，Git 僅僅是把 HEAD 從指向版本三，改爲了指向版本二；
至此，Git 的版本回退已介紹完畢，大家如果有什麼不明白的可以在評論區留言。