快畢業了，張小明要完成畢業論文，限期3個月完成。負責論文的李老師會定期要學生上交論文，抽查論文完成的情況。而且還規定要保留原稿，以證明論文不是抄襲的。
由於論文篇幅很長，內容繁雜，而且那時候還沒有計算機，不能寫電子文檔，修修改改是避免不了的，所以張小明自己想了一個法子，來對付論文。
張小明每次寫一段論文時，都先在草稿本上寫，哪怕修修改改寫的很亂也沒有關係，因為只有他一個人看得到。在草稿本上修改完成之後，就謄寫到正式的論文報告本上。
如果謄寫到論文報告本上發現也還有錯誤，需要修改，那麼就得刪掉有錯誤的那一頁，在草稿本上修改之後再重新謄寫到論文報告本上。
情景1
一天上午張小明在草稿本上寫了一段文字並謄寫到了論文報告本上，下午準備接著在草稿本上寫。可是那天狀態不好，寫出的東西不滿意，越看越亂，一怒之下，張小明把草稿本撕了。由於需要保留草稿，張小明只好新買了一個草稿本，並將論文報告本上的內容複印到新的草稿文檔上。
情景2
靜下心來之後終於在草稿本上寫了一段論文，然後就謄寫到論文報告本上了。但再讀之後卻發現了很多錯誤。此時論文報告本和草稿本上都是有錯誤的論文，根本不知道如何回到上次修改的地方了，只好找李老師要回了上次提交的版本，並複印到論文報告本上。注意此時草稿本上的內容並沒有刪掉。
一個星期後，李老師要求檢查論文報告。張小明只寫了一點，心想，MMP，這可怎麼拿得出手哦，順手在草稿文檔上寫下了‘MMP李老師’。李老師催的急，無奈張小明只好將論文報告複製一份，交給了李老師，並在日誌中記錄如下：第一次提交給李老師論文報告。不過草稿上的那一句MMP，李老師是看不到的，哈哈。
發洩歸發洩，論文上交之後還得繼續寫。張小明刪掉了那句MMP，此時草稿本上的論文和論文報告本上的論文完全一致了，即是乾淨的。
李老師收到張小明的論文報告本之後，也寫下日誌：張小明第一次提交的論文ver 0.1。此後每一個星期，張小明都會提交一個版本給李老師檢查，李老師已經保存了5個版本。每次收到論文，李老師都會寫下日誌，並把最新的論文報告本放在最上面，並把它叫
HEAD。情景3
有一次李老師因論文格式問題批評了張小明，張小明恨恨的在草稿本上畫了一隻烏龜。碰巧那天李老師又要檢查論文，張小明同學聚會喝了點酒，想也沒想照著草稿把烏龜也畫在論文報告本上，然後上交了。
李老師再次收到張小明的論文報告本後，繼續寫下日誌：張小明第6次提交的論文ver 0.6，並把這個最新的版本放在最上面。當李老師打開論文報告本，看見論文最後畫了一隻烏龜後氣壞了，立馬通知張小明重新交一個版本上來。
學校系領導規定學生每次上交的論文報告版本也要存檔，以便抽查。李老師也很無奈，這麼不雅的論文是不能放在臺面上的，只好把上次的論文報告本放在了最上面，並告知張小明，李老師要交給系領導抽查的論文報告版本為上次的ver 0.5，這次提交的版本已棄置不用。
由於張小明的論文報告本和草稿本已經畫了烏龜，而且他並不知道李老師所說的ver 0.5版本是哪個樣子的了，他只好找李老師複印了兩份ver 0.5版本的論文，作為新的論文報告和草稿。如果此前提交第6次論文報告後，又在草稿或論文報告本上寫了新的東西，那麼新的內容就丟失了。
再回到我們使用git時的情景，是不是和上面的故事有點類似呢。有點git基礎的同學都知道git也有 兩個區，工作區，暫存區，以及主分支master和指向master的指針HEAD，正好對應故事中的草稿本，論文報告本，和老師的版本庫。
我們在git版本控制下寫代碼時，相當於往草稿本上寫代碼。git add file命令就是把草稿文檔謄寫到正式的論文報告本上。git commit命令相當於提交給老師。
情景一，就是利用git checkout -- file命令把草稿本上新寫的內容擦掉，即讓工作區的代碼和暫存區或最新版本庫的一致。
情景二，就是利用git reset HEAD file命令把論文報告本上新寫的內容擦掉，即讓暫存區和最新版本庫一致，此時草稿本或工作區內容不會被擦除。
情景三，就是利用git reset -- hard verid 命令讓論文報告本和草稿本上的內容與指定的版本一致，即讓暫存區和工作區與指定版本庫一致。
閱讀更多 程序猿的內心獨白 的文章
