理解git結構與簡單操做（二）工做區與暫存區

工做區

其實工做區沒什麼好講的，這個區域其實就是抽象了你的磁盤文件自己。

工做區就是你正在修改的那寫文件們！

可是，單獨抽象出工做區對於git概念的總體理解是至關有必要的。

好比說，工做區實際上是整個git流程的源頭，你對工做區的修改其實就是git要保存的對象。因此，當你修改工做區完成（寫完代碼），將修改從工做區提交到遠程倉庫的流程中工做區的內容是絕對不會變的。簡而言之，在提交的流程中只有你本身去修改文件，git不會去動。

可是，當你發現你修改錯誤以後，就能夠借用git版本庫和暫存區的內容反向修改工做區。好比：

• 將暫存區的改動同步到工做區，就是git checkout。
• 將版本庫的代碼同步到工做區，就是git reset HEAD <commitId> --hard。

這種對於工做區的修改實際上是很是危險的：若是你將改動checkout掉，在沒有手動備份的狀況下你修改的這部份內容就找不回來了。因此，修改代碼要謹慎，checkout要謹慎，版本回退要謹慎。

涉及操做：git checkout, git reset HEAD <commitId> --hard

暫存區

暫存區的概念雖然在全部git教程中都是重點提到的內容，可是實際工做中大部分同窗對此都是懵懵懂懂。我認爲，這是由於暫存區的英文翻譯致使的╮(╯▽╰)╭。

暫存區的英文名稱叫stage。這個stage呢，既是個名詞也是個動詞，可是都沒有「存儲」的意思，這是不少人疑惑的地方。咱們從暫存區的做用來看看stage究竟是什麼意思。

在用git提交的過程當中，每當工做區發生了修改，git status就會顯示你修改的文件爲紅色，表明這些文件發生過修改。

上面提到了，這些文件在git裏叫作「Changes not staged for commit」(git status能夠顯示工做區修改、暫存區文件以及你本地分支相對於遠程分支的狀況)。而當你執行git add <filepath>以後，這些文件就變成了綠色，如圖：

綠色的文件git稱之爲「Changes to be committed」，就是將要被提交的修改。也就是說，暫存區會集中一批修改，統一提交成一個commit。

舉個例子，git的提交流程就像是一個生產流水線：你先咔咔生產一批產品（修改文件），而後把生產好的文件放到一個存放的地方（git add到暫存區），當你以爲這批貨無論是質量仍是數量都OK了，就把這批貨打包裝箱（git commit）。

這樣就明白暫存區是啥意思了吧。因此我認爲，暫存區存在的意義就是規範你的每一次commit。你能夠把暫存區想象成一個分支的一次commit的內容，執行git commit提交時就把暫存區這個commit放到現有分支的頂端。

還有不少人不理解暫存區和工做區的關係，有一種狀況能夠加深對其的理解：當你把一個文件的修改add到暫存區以後，再次從工做區修改這個文件，會出現這樣的狀況：

這說明暫存區和工做區是分開的。暫存區保存的是當你add時修改的內容，而你再次修改工做區時，git又會檢測到你的修改跟暫存區中的不同，就出現了未暫存和已暫存同時出現的狀況，這時繼續git add，暫存區中的修改就會集中這兩次的修改內容，而後commit就會把兩次修改提交成同一個了。

綜上所述，暫存區stage的英文含義像是一個階段性的平臺，用來保存你即將打包成一次commit的提交們。從英文含義角度理解，這個詞兒其實仍是挺生動形象的。（emmmmmm......）

而暫存區的修改是如何同步到文件區呢？ 在說暫存區時已經提到過，答案就是git checkout <filename>啦。checkout就是「檢出」的意思，當出現上面圖中暫存區和工做區都有修改的時候，checkout會從暫存區「檢出」修改到工做區中，使工做區與暫存區同步（關於checkout其餘用法後面再說）。

最後，已經在暫存區中的修改如何去掉，git已經提示了：「git reset HEAD <file>...」。觀感上，就是把暫存區中的某些修改從中刪去了，實際上，這個git reset的操做是從版本庫同步代碼到暫存區中的意思。也就是說，在這裏的git reset完成了使用版本庫的代碼修改暫存區的操做。

涉及操做：git status, git add, git commit, git checkout, git reset HEAD <file>

文章連接

理解git結構與簡單操做（一）git的本質

理解git結構與簡單操做（二）工做區與暫存區

理解git結構與簡單操做（三）認識版本庫與分支

理解git結構與簡單操做（四）合併分支的方法與策略