自然，你是不會犯錯的。不過現在是淩晨兩點，你正在趕一份工作報告，你在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>

git reset命令既可以回退版本，也可以把暫存區的修改回退到工作區。當我們用HEAD時，表示最新的版本。

再用git status查看一下，現在暫存區是幹凈的，工作區有修改：

還記得如何丟棄工作區的修改嗎？

整個世界終於清靜了！

現在，假設你不但改錯了東西，還從暫存區提交到了版本庫，怎麽辦呢？還記得版本回退一節嗎？可以回退到上一個版本。不過，這是有條件的，就是你還沒有把自己的本地版本庫推送到遠程。還記得Git是分布式版本控制系統嗎？我們後面會講到遠程版本庫，一旦你把stupid boss提交推送到遠程版本庫，你就真的慘了……

小結

又到了小結時間。

場景1：當你改亂了工作區某個文件的內容，想直接丟棄工作區的修改時，用命令git checkout -- file。

場景2：當你不但改亂了工作區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場景1，第二步按場景1操作。

場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。

Git(撤銷修改)