現在，假定你已經完全掌握了暫存區的概念。下面，我們要討論的就是，為什麼git比其他版本控制系統設計得優秀，因為git跟蹤並管理的是修改，而非檔案。你會問，什麼是修改？比如你新增了一行，這就是乙個修改，刪除了一行，也是乙個修改， 更改了某些字元，也是乙個修改，刪了一些又加了一些，也是乙個修改，甚至建立乙個新檔案，也算乙個修改。為什麼說git管理的是修改，而不是檔案呢？我們還是做實驗。
第一步，對readme.txt做乙個修改，比如加一行內容：「第四次新增文字資訊」。
第二步：修改之後我們使用
git add readme.txt新增到暫存區。
第三步，再對readme.txt做修改新增一行文字：「第五次修改文字資訊」。
第四步：提交所有修改:
git commit -m"提交第四次和第五次文字文字修改"
第五步：檢視提交之後的狀態：
「 changes not staged for commit」這行說明已跟蹤檔案的內容發生了變化,但還沒有放到暫存區。咦，怎麼第五次的修改沒有被提交？
別激動，我們回顧一下操作過程：
第四次修改 -> git add -> 第五次修改 -> git commit。
你看，我們前面講了，git管理的是修改，當你用「git add」命令後，在工作區的第四次修改被放入暫存區，準備提交，但是，在工作區的第五次修改並沒有放入暫存區，所以，「git commit」只負責把暫存區的修改提交了，也就是第四次的修改被提交了，第五次 的修改不會被提交。
提交後，用「
git diff head -- readme.txt」
命令可以檢視工作區和版本庫裡面最新版本的區別：
可見，第五次修改確實沒有被提交。那怎麼提交第五次修改呢？你可以繼續add再commit，也可以別著急提交第四次修改，先add第五次修改，再commit，就相當於把兩次修改合併後一塊提交了：
第四次修改 -> add -> 第五次修改 -> add -> commit。
好，現在，把第五次修改提交了，然後開始小結。
現在，你又理解了git是如何跟蹤修改的，每次修改，如果不add到暫存區，那就不會加入到commit中。
Git 管理修改
現在，假定你已經完全掌握了暫存區的概念。下面，我們要討論的就是，為什麼git比其他版本控制系統設計得優秀，因為git跟蹤並管理的是修改，而非檔案。你會問，什麼是修改？比如你新增了一行，這就是乙個修改，刪除了一行，也是乙個修改，更改了某些字元，也是乙個修改，刪了一些又加了一些，也是乙個修改，甚至建立乙...
Git 管理修改
現在，假定你已經完全掌握了暫存區的概念。下面，我們要討論的就是，為什麼git比其他版本控制系統設計得優秀，因為git跟蹤並管理的是修改，而非檔案。你會問，什麼是修改？比如你新增了一行，這就是乙個修改，刪除了一行，也是乙個修改，更改了某些字元，也是乙個修改，刪了一些又加了一些，也是乙個修改，甚至建立乙...
Git管理修改
為什麼git比其他版本控制系統設計得優秀？因為git跟蹤並管理的是修改，而非檔案 修改 比如新增了一行 刪除了一行 更改了某些字元，這些都是乙個修改 為什麼說git跟蹤管理的是修改？這時候，可以做個實驗證明，例如修改某一檔案 下述test.txt 內容 然後將修改後的test.txt檔案新增到暫存區...