Git工作区、暂存区和版本库

基本概念

我们先来理解下 Git 工作区、暂存区和版本库概念：

• 工作区：就是你在电脑里能看到的目录。
• 暂存区：英文叫 stage 或 index。一般存放在 .git 目录下的 index 文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
• 版本库：工作区有一个隐藏目录 .git，这个不算工作区，而是 Git 的版本库。

下面这个图展示了工作区、版本库中的暂存区和版本库之间的关系：

图中左侧为工作区，右侧为版本库。在版本库中标记为 “index” 的区域是暂存区（stage/index），标记为 “master” 的是 master 分支所代表的目录树。

图中我们可以看出此时 “HEAD” 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。

图中的 objects 标识的区域为 Git 的对象库，实际位于 “.git/objects” 目录下，里面包含了创建的各种对象及内容。

当对工作区修改（或新增）的文件执行 git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。

当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。

当执行 git reset HEAD 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。

当执行 git rm --cached 命令时，会直接从暂存区删除文件，工作区则不做出改变。

当执行 git checkout . 或者 git checkout – 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区中的改动。

当执行 git checkout HEAD . 或者 git checkout HEAD 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

文件状态

在工作目录下的每一个文件都不外乎这两种状态：已跟踪 或 未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后， 它们的状态可能是未修改，已修改或已放入暂存区。简而言之，已跟踪的文件就是 Git 已经知道的文件。

工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有被放入暂存区。 初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态，因为 Git 刚刚检出了它们， 而你尚未编辑过它们。

编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git 将它们标记为已修改文件。 在工作时，你可以选择性地将这些修改过的文件放入暂存区，然后提交所有已暂存的修改，如此反复。

我们可以先创建一个git仓库，然后通过对文件执行各种git命令从而更好地理解文件状态不断地变化。

创建一个git仓库
在仓库目录下新建一个文件README.rb，在没有对文件执行git指令的情况下，通过git status查看此时该文件的状态。

从以上我们可以看到，当没有对文件执行任何git操作时，该文件此时的状态是处于Untracked(未跟踪)，同时该文件目前处于git仓库的工作目录下，接下来我们用git add .将文件从工作目录提交到暂存区。

此时，文件已经从工作目录被提交到暂存区，同时文件状态已不再是未跟踪，而变成了已跟踪。根据提示，当我们要将文件从暂存区中删除时，可以直接用git rm --cached README.rb命令，删除后该文件不再出现在暂存区，只存在于工作目录下。
最后，当文件被提交至暂存区时，我们就可以通过git commit将文件从暂存区提交到版本库中，该文件已正式纳入到Git版本控制中。
当把文件提交到版本库后才发现有一些内容还需要修改，修改后文件相当于又回到了工作目录下，需要重新git add和gitcommit。文件状态从Unmodified变成Modified。

注意：文件被提交到版本库中需要先提交到暂存区中，否则会commit失败。

当我发现这个文件已不再需要时便可将其删除。

在工作目录下将文件删除后轨迹仍然存在，可以用git add、git commit重新提交一遍，也可以用git rm README.rb将其从暂存区删除后再commit。