像這樣，你不斷對文件進行修改，然后不斷提交修改到版本庫里，就好比玩RPG游戲時，每通過一關就會自動把游戲狀態存盤，如果某一關沒過去，你還可以選擇讀取前一關的狀態。有些時候，在打Boss之前，你會手動存盤，以便萬一打Boss失敗了，可以從最近的地方重新開始。Git也是一樣，每當你覺得文件修改到一定程度的時候，就可以“保存一個快照”，這個快照在Git中被稱為commit。一旦你把文件改亂了，或者誤刪了文件，還可以從最近的一個commit恢復，然后繼續工作，而不是把幾個月的工作成果全部丟失

現在，我們回顧一下readme.txt文件一共有幾個版本被提交到Git倉庫里了

版本1：wrote a readme file

版本2：add distributed

版本3：append GPL

當然了，在實際工作中，我們腦子里怎么可能記得一個幾千行的文件每次都改了什么內容，不然要版本控制系統干什么。版本控制系統肯定有某個命令可以告訴我們歷史記錄，在Git中，我們用git log命令查看

git log命令顯示從最近到最遠的提交日志，我們可以看到3次提交，最近的一次是append GPL，上一次是add distributed，最早的一次是wrote a readme file

需要友情提示的是，你看到的一大串類似3628164…882e1e0的是commit id（版本號），和SVN不一樣，Git的commit id不是1，2，3……遞增的數字，而是一個SHA1計算出來的一個非常大的數字，用十六進制表示，而且你看到的commit id和我的肯定不一樣，以你自己的為準。為什么commit id需要用這么一大串數字表示呢？因為Git是分布式的版本控制系統，后面我們還要研究多人在同一個版本庫里工作，如果大家都用1，2，3……作為版本號，那肯定就沖突了

好了，現在我們啟動時光穿梭機，準備把readme.txt回退到上一個版本，也就是“add distributed”的那個版本，怎么做呢？

首先，Git必須知道當前版本是哪個版本，在Git中，用HEAD表示當前版本，也就是最新的提交3628164…882e1e0（注意我的提交ID和你的肯定不一樣），上一個版本就是HEAD^，上上一個版本就是HEAD^^，當然往上100個版本寫100個^比較容易數不過來，所以寫成HEAD~100

現在，我們要把當前版本“append GPL”回退到上一個版本“add distributed”，就可以使用git reset命令：

看看readme.txt的內容是不是版本add distributed

果然。還可以繼續回退到上一個版本wrote a readme file，不過且慢，然我們用git log再看看現在版本庫的狀態

最新的那個版本append GPL已經看不到了！好比你從21世紀坐時光穿梭機來到了19世紀，想再回去已經回不去了，腫么辦？

辦法其實還是有的，只要上面的命令行窗口還沒有被關掉，你就可以順著往上找啊找啊，找到那個append GPL的commit id是3628164…，于是就可以指定回到未來的某個版本

再小心翼翼地看看readme.txt的內容

Git的版本回退速度非常快，因為Git在內部有個指向當前版本的HEAD指針，當你回退版本的時候，Git僅僅是把HEAD從指向append GPL

然后順便把工作區的文件更新了。所以你讓HEAD指向哪個版本號，你就把當前版本定位在哪

在Git中，總是有后悔藥可以吃的。當你用$ git reset –hard HEAD^回退到add distributed版本時，再想恢復到append GPL，就必須找到append GPL的commit id。Git提供了一個命令git reflog用來記錄你的每一次命令

終于舒了口氣，第二行顯示append GPL的commit id是3628164，現在，你又可以乘坐時光機回到未來了

總結：

- HEAD指向的版本就是當前版本，因此，Git允許我們在版本的歷史之間穿梭，使用命令git reset –hard commit_id

- 穿梭前，用git log可以查看提交歷史，以便確定要回退到哪個版本

- 要重返未來，用git reflog查看命令歷史，以便確定要回到未來的哪個版本

總結

以上是生活随笔為你收集整理的Git之版本回退的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。