今天面試時被問到git本地倉庫的一些原理問題，差點吐出一口老血，這些東西只有一點模糊的印象了，憑着印象瞎答了一通，完事又上網重新看了一遍。建議童鞋們以後遇到這種原理問題就說不記得，工具性的知識原理沒必要每次用工具時都梳理一遍吧，具體問題具體分析咯！
原文地址。
工作區、暫存區（index）、版本庫
其實呢，工作區、提交區/暫存區（stage/index）、版本庫的概念問題，從上圖中就能看的很清楚，本來不想細講的，但想想還是說一下。Git與其他版本版本控制器其中之一的不同之處就在於有提交區/暫存區（stage/index）的概念。下面我們先來看一下工作區：
其實呢，工作區就是我們開發目錄了，在電腦中是可能看到的，比如我們這裏的pro目錄，就是一個工作區。大家再來看一下，下面的兩張圖：
大家可以看到，工作區中有個隱藏的目錄“.git”，這個不是工作區哦，這個就是Git的版本庫。大家再看下面兩張圖：
大家可以看到，在“.git”目錄中有很多文件，其中一個重要的文件index，就是我們說的提交區/暫存區（stage/index）。暫存區（stage, index）是 Git 最重要的概念之一，理解了這個概念很多 Git 命令就不再那麼神祕了。對於 Git 暫存區（stage） ，不知道您的感想如何？
-
“被眼花繚亂的 Git 魔法徹底搞糊塗了？”
-
“Git 爲什麼這麼折磨人，修改的文件直接提交不就完了麼？”
-
“看不出 Git 這麼做有什麼好處？”
我認爲 Git 暫存區（stage或稱爲 index）的設計是 Git 最成功的設計之一，也是最難理解的一個設計。 在版本庫（.git）目錄下，有一個 index 文件，相信大家在上圖中已經看到了。下面我們好好說一說他們之間關係，同樣的我們先看一張圖：
在上圖中，我們可以看到部分 Git 命令是如何影響工作區和暫存區（stage/index）的。
-
圖中左側爲工作區，右側爲版本庫。在版本庫中標記爲 "index" 的區域是暫存區（stage/index），標記爲 "master" 的是 master 分支所代表的目錄樹（關於分支問題在下面的文章中會詳解）。
-
圖中我們可以看出此時 "HEAD" 實際是指向 master 分支的一個“指針”。所以，圖示的命令中出現 HEAD 的地方可以用 master 來替換（HEAD的概念我們在後面的文章中也會詳解）。
-
圖中的 objects 標識的區域爲 Git 的對象庫，實際位於 ".git/objects" 目錄下，我們會在後面的文章中將重點介紹，嘿嘿！。
-
當對工作區新增或修改的文件執行 "git add" 命令時，暫存區的目錄樹被更新，同時工作區新增或修改的文件內容被寫入到對象庫中的一個新的對象中，而該對象的ID被記錄在暫存區的文件索引中。（如上圖）
-
當執行提交操作 "git commit" 時，暫存區的目錄樹寫到版本庫的對象庫（objects）中，master 分支會做相應的更新。即 master 指向的目錄樹就是提交時暫存區的目錄樹。（如上圖）
-
當執行 "git reset HEAD" 命令時，暫存區的目錄樹會被重寫，被 master 分支指向的目錄樹所替換，但是工作區不受影響。 當執行 "git rm --cached <file>" 命令時，會直接從暫存區刪除文件，工作區則不做出改變。
-
當執行 "git checkout ." 或者 "git checkout -- <file>" 命令時，會用暫存區全部或指定的文件替換工作區的文件。這個操作很危險，會清除工作區中未添加到暫存區的改動。
-
當執行 "git checkout HEAD ." 或者 "git checkout HEAD <file>" 命令時，會用 HEAD 指向的 master 分支中的全部或者部分文件替換暫存區和以及工作區中的文件。這個命令也是極具危險性的，因爲不但會清除工作區中未提交的改動，也會清除暫存區中未提交的改動。
好了，到這裏我們的工作區、暫存區、版本庫就講解到這裏了，