自然，你是不會犯錯的。不過現在是凌晨兩點，你正在趕一份工作報告，你在readme.txt中添加了一行：
在你准備提交前，一杯咖啡起了作用，你猛然發現了stupid boss可能會讓你丟掉這個月的獎金！
既然錯誤發現得很及時，就可以很容易地糾正它。你可以刪掉最后一行，手動把文件恢復到上一個版本的狀態。如果用git status查看一下：
你可以發現，Git會告訴你，git checkout -- file可以丟棄工作區的修改：
命令git checkout -- readme.txt意思就是，把readme.txt文件在工作區的修改全部撤銷，這里有兩種情況：
一種是readme.txt自修改后還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；
一種是readme.txt已經添加到暫存區后，又作了修改，現在，撤銷修改就回到添加到暫存區后的狀態。
總之，就是讓這個文件回到最近一次git commit或git add時的狀態。
git checkout -- file命令中的--很重要，沒有--，就變成了“切換到另一個分支”的命令，我們在后面的分支管理中會再次遇到git checkout命令。
現在假定是凌晨3點，你不但寫了一些胡話，還git add到暫存區了：
慶幸的是，在commit之前，你發現了這個問題。用git status查看一下，修改只是添加到了暫存區，還沒有提交：
Git同樣告訴我們，用命令git reset HEAD <file>可以把暫存區的修改撤銷掉（unstage），重新放回工作區：
git reset命令既可以回退版本，也可以把暫存區的修改回退到工作區。當我們用HEAD時，表示最新的版本。
再用git status查看一下，現在暫存區是干凈的，工作區有修改：
還記得如何丟棄工作區的修改嗎？
整個世界終於清靜了！
現在，假設你不但改錯了東西，還從暫存區提交到了版本庫，怎么辦呢？還記得版本回退一節嗎？可以回退到上一個版本。不過，這是有條件的，就是你還沒有把自己的本地版本庫推送到遠程。還記得Git是分布式版本控制系統嗎？我們后面會講到遠程版本庫，一旦你把stupid boss提交推送到遠程版本庫，你就真的慘了……
小結
又到了小結時間。
場景1：當你改亂了工作區某個文件的內容，想直接丟棄工作區的修改時，用命令git checkout -- file。
場景2：當你不但改亂了工作區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場景1，第二步按場景1操作。
場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。