您好,登錄后才能下訂單哦!
為什么Git比其他版本控制系統設計得優秀,因為Git跟蹤并管理的是修改,而非文件。
你會問,什么是修改?比如你新增了一行,這就是一個修改,刪除了一行,也是一個修改,更改了某些字符,也是一個修改,刪了一些又加了一些,也是一個修改,甚至創建一個新文件,也算一個修改。
為什么說Git管理的是修改,而不是文件呢?我們還是做實驗。第一步,對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.
然后,添加:
$ 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.txt index 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.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. 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.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 checkout -- file命令中的--很重要,沒有--,就變成了“切換到另一個分支”的命令,我們在后面的分支管理中會再次遇到git checkout命令。
現在假定是凌晨3點,你不但寫了一些胡話,還git add到暫存區了:
$ 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. 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.txt Unstaged 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 master nothing 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.txt rm '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其實是用版本庫里的版本替換工作區的版本,無論工作區是修改還是刪除,都可以“一鍵還原”。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。