為什么Git比其他版本控制系統設計得優秀，因為Git跟蹤并管理的是修改，而非文件。
你會問，什么是修改？比如你新增了一行，這就是一個修改，刪除了一行，也是一個修改，更改了某些字符，也是一個修改，刪了一些又加了一些，也是一個修改，甚至創建一個新文件，也算一個修改。
為什么說Git管理的是修改，而不是文件呢？我們還是做實驗。第一步，對readme.txt做一個修改，比如加一行內容：
$ cat readme.txtGit is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes.
然后，添加：
$ git add readme.txt$ git status# On branch master# Changes to be committed:# (use "git reset HEAD <file>..." to unstage)## modified: readme.txt#
然后，再修改readme.txt：
$ cat readme.txt Git is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files.
提交：
$ git commit -m "git tracks changes"[master d4f25b6] git tracks changes 1 file changed, 1 insertion(+)
提交后，再看看狀態：
$ git status# On branch master# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)## modified: readme.txt#no changes added to commit (use "git add" and/or "git commit -a")
咦，怎么第二次的修改沒有被提交？
別激動，我們回顧一下操作過程：
第一次修改 -> git add -> 第二次修改 -> git commit
你看，我們前面講了，Git管理的是修改，當你用git add命令后，在工作區的第一次修改被放入暫存區，準備提交，但是，在工作區的第二次修改并沒有放入暫存區，所以，git commit只負責把暫存區的修改提交了，也就是第一次的修改被提交了，第二次的修改不會被提交。
提交后，用git diff HEAD -- readme.txt命令可以查看工作區和版本庫里面最新版本的區別：
$ git diff HEAD -- readme.txt diff --git a/readme.txt b/readme.txtindex 76d770f..a9c5755 100644--- a/readme.txt+++ b/readme.txt@@ -1,4 +1,4 @@ Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage.-Git tracks changes.+Git tracks changes of files.
可見，第二次修改確實沒有被提交。
那怎么提交第二次修改呢？你可以繼續git add再git commit，也可以別著急提交第一次修改，先git add第二次修改，再git commit，就相當于把兩次修改合并后一塊提交了：
第一次修改 -> git add -> 第二次修改 -> git add -> git commit
好，現在，把第二次修改提交了，然后開始小結。
自然，你是不會犯錯的。不過現在是凌晨兩點，你正在趕一份工作報告，你在readme.txt中添加了一行：
$ cat readme.txtGit is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files.My stupid boss still prefers SVN.
在你準備提交前，一杯咖啡起了作用，你猛然發現了“stupid boss”可能會讓你丟掉這個月的獎金！
既然錯誤發現得很及時，就可以很容易地糾正它。你可以刪掉最后一行，手動把文件恢復到上一個版本的狀態。如果用git status查看一下：
$ git status# On branch master# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)## modified: readme.txt#no changes added to commit (use "git add" and/or "git commit -a")
你可以發現，Git會告訴你，git checkout -- file可以丟棄工作區的修改：
$ git checkout -- readme.txt
命令git checkout -- readme.txt意思就是，把readme.txt文件在工作區的修改全部撤銷，這里有兩種情況：
一種是readme.txt自修改后還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀態；
一種是readme.txt已經添加到暫存區后，又作了修改，現在，撤銷修改就回到添加到暫存區后的狀態。
總之，就是讓這個文件回到最近一次git commit或git add時的狀態。
現在，看看readme.txt的文件內容：
$ cat readme.txtGit is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files.
文件內容果然復原了。
git checkout -- file命令中的--很重要，沒有--，就變成了“切換到另一個分支”的命令，我們在后面的分支管理中會再次遇到git checkout命令。
現在假定是凌晨3點，你不但寫了一些胡話，還git add到暫存區了：
$ cat readme.txtGit is a distributed version control system.Git is free software distributed under the GPL.Git has a mutable index called stage.Git tracks changes of files.My stupid boss still prefers SVN.$ git add readme.txt
慶幸的是，在commit之前，你發現了這個問題。用git status查看一下，修改只是添加到了暫存區，還沒有提交：
$ git status# On branch master# Changes to be committed:# (use "git reset HEAD <file>..." to unstage)## modified: readme.txt#
Git同樣告訴我們，用命令git reset HEAD file可以把暫存區的修改撤銷掉（unstage），重新放回工作區：
$ git reset HEAD readme.txtUnstaged changes after reset:M readme.txt
git reset命令既可以回退版本，也可以把暫存區的修改回退到工作區。當我們用HEAD時，表示最新的版本。
再用git status查看一下，現在暫存區是干凈的，工作區有修改：
$ git status# On branch master# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)## modified: readme.txt#no changes added to commit (use "git add" and/or "git commit -a")
還記得如何丟棄工作區的修改嗎？
$ git checkout -- readme.txt$ git status# On branch masternothing to commit (working directory clean)
整個世界終于清靜了！
現在，假設你不但改錯了東西，還從暫存區提交到了版本庫，怎么辦呢？git可以回退到上一個版本。不過，這是有條件的，就是你還沒有把自己的本地版本庫推送到遠程。一旦你把“stupid boss”提交推送到遠程版本庫，你就真的慘了
在Git中，刪除也是一個修改操作，我們實戰一下，先添加一個新文件test.txt到Git并且提交：
$ git add test.txt$ git commit -m "add test.txt"[master 94cdc44] add test.txt 1 file changed, 1 insertion(+) create mode 100644 test.txt
一般情況下，你通常直接在文件管理器中把沒用的文件刪了，或者用rm命令刪了：
$ rm test.txt
這個時候，Git知道你刪除了文件，因此，工作區和版本庫就不一致了，git status命令會立刻告訴你哪些文件被刪除了：
$ git status# On branch master# Changes not staged for commit:# (use "git add/rm <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)## deleted: test.txt#no changes added to commit (use "git add" and/or "git commit -a")
現在你有兩個選擇，一是確實要從版本庫中刪除該文件，那就用命令git rm刪掉，并且git commit：
$ git rm test.txtrm 'test.txt'$ git commit -m "remove test.txt"[master d17efd8] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt
現在，文件就從版本庫中被刪除了。
另一種情況是刪錯了，因為版本庫里還有呢，所以可以很輕松地把誤刪的文件恢復到最新版本：
$ git checkout -- test.txt
git checkout其實是用版本庫里的版本替換工作區的版本，無論工作區是修改還是刪除，都可以“一鍵還原”。
新聞熱點
疑難解答
圖片精選
