我們新增並提交了一個readme.txt檔案，現在我們繼續來修改這個檔案，在檔案的後面我新增一行。

然後執行命令  git status 來檢視結果如何：

git status 命令可以讓我們時刻掌握當前的狀態，上面命令告訴我們，readme.txt被修改了，但是還沒有準備提交的修改。雖然Git告訴我們readme.txt被修改了，如果我們不知道上次修改了readme.txt什麼內容，可以通過 git diff 這個命令檢視:

git diff 就是檢視difference，顯示的格式是Unix通用的diff格式，可以從圖片看出，我在最後一行添加了一句話，綠色的那一行是我後面修改的。

知道了readme.txt做了什麼修改後，將它提交到倉庫就安心多了，提交修改和提交新檔案是一樣的兩步，第一步: git add

在執行第二步: git commit 之前，我們可以執行 git status 檢視當前倉庫的狀態:

git status 告訴我們，將要被提交的修改包括readme.txt，下一步就可以放心地提交:(-m 引數參考上一篇文章的解釋)

提交後再使用git status命令檢視倉庫的當前狀態:

Git告訴我們當前沒有需要提交的修改，而且，工作目錄是乾淨（working tree clean）的。

上面所有的內容就介紹了兩個命令，git status

版本回退

上面已經學會了修改檔案，然後把修改提交到Git版本庫，這裡再修改一次來測試我的版本回退。

這裡通過Git中的命令 git log 來檢視修改的歷史記錄。該命令顯示從最近到最遠的提交日誌，如果嫌輸出資訊太多，看得眼花繚亂的，可以試試加上--pretty=oneline只寫 --onleline也可以，只會顯示commit id 的前幾個字元

這裡看到的一大串的黃色字元是 commit id(提交的版本號)，和SVN不一樣，Git的commit id不是1，2，3...遞增的數字，而是一個SHA1計算出來的數字，用十六進位制表示。

現在我需要把readme.txt回退到上一個版本，這裡也就是 測試修改 那個版本，這裡使用 git reset 命令: git reset --hard HEAD^

首先，Git必須知道當前版本是哪個版本，在Git中，用HEAD表示當前版本，也就是最新的提交上一個版本就是HEAD^，上上一個版本就是HEAD^^，當然往上100個版本寫100個^比較容易數不過來，所以寫成HEAD~100。

這裡可以看到執行命令後再檢視readme.txt中的內容變成了我第二次修改的資料。果然還原到上一個版本了（測試修改 版本）

這裡用git log 再檢視下現在的版本庫狀態:

可以看到最新的那個版本 從繼續修改 變成了測試修改 ，好比你從21世紀坐時光穿梭機來到了19世紀，想再回去已經回不去了，腫麼辦？辦法其實還是有的，只要上面的命令列視窗還沒有被關掉，你就可以順著往上找啊找啊，找到那個繼續修改的commit id於是就可以指定回到未來的某個版本，這裡的commit id(版本號)沒有必要寫全，前幾位就可以，Git會自動去找。當然也不能只寫前一兩位，因為Git可能會找到多個版本號，就無法確定是哪一個了。

檢視teadme.txt的內容，又變成了原來最新的內容了。

Git版本的回退速度特別快，因為Git在內部有個指向當前版本的HEAD指標，Git僅僅是把 HEAD 從 繼續修改:

改為指向 測試修改:

然後順便把工作區的檔案更新了，所有你讓HEAD指向哪個版本號，你就把當前版本定位在哪？

現在，你回退到了某個版本，關閉Git，想恢復到新版本怎麼辦？找不到新版本的commit id怎麼辦？

在Git中，總是有後悔藥可以吃的。當你用$ git reset --hard HEAD^回退到 測試修改 版本時，再想恢復到 繼續修改，就必須找到 繼續修改 的commit id。Git提供了一個命令git reflog用來記錄你的每一次命令：

於是你就知道了 繼續修改 的commit id是多少了，執行git reset就可以回到 繼續修改 了

關於版本回退的小總結

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

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

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