Git的工做区、暂存区和版本库之间的关系及其互操做

工做区，暂存区和版本库之间的关系

工做区：咱们会想固然的认为，当前仓库所在目录就是咱们的工做区，其实这是不彻底正确的。在当前仓库中，新增，更改，删除文件这些动做，都发生在工做区里面。

 

暂存区：英文叫stage, 或index。在版本库.git）目录下，有一个index文件。它实际上就是一个包含文件索引的目录树，像是一个虚拟的工做区。在这个虚拟工做区的目录树中，记录了文件名、文件的状态信息（时间戳、文件长度等），文件的内容并不存储其中，而是保存在Git对象库（.git/objects）中，文件索引创建了文件和对象库中对象实体之间的对应。若是当前仓库，有文件更新，而且使用git

 add 命令，那么这些更新就会出如今暂存区中。

 

版本库：当前仓库下，若是没有任何的提交，那么版本库就是对应上次提交后的内容。下面这个图展现了工做区、版本库中的暂存区和版本库之间的关系。

 

 

图中左侧为工做区，右侧为版本库。在版本库中标记为 "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 <file>" 命令时，会直接从暂存区删除文件，工做区则不作出改变。

 

  当执行 "git checkout ." 或者 "git checkout -- <file>" 命令时，会用暂存区所有或指定的文件替换工做区的文件。这个操做很危险，会清除工做区中未添加到暂存区的改动。

 

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

 

使用git diff查看各个区之间的差别

git diff 和 git diff --cached容易混淆

 

  git diff 比较的是工做区和暂存区的差异

 

  git diff --cached 比较的是暂存区和版本库的差异

 

  git diff HEAD 能够查看工做区和版本库的差异

 

  每次commit后,git diff --cached没有内容，是由于暂存区的内容已经更新到版本库中，所以暂存区和版本库中的内容无差异

git reset和git revert的区别

reset是重置，默认是git reset --mixed <commit> 可让版本库重置到某个commit状态，该commit以后的commit不会保留，并重置暂存区，可是不改变工做区。即这个时候，上次提交的内容在工做区中还会存在。

  若是使用git reset --hard <commit> 将版本库，暂存区和工做区的内容所有重置为某个commit的状态。以前的commit不会保留。

  revert比reset更加温柔一点，回滚到某次commit且该commit以后的提交记录都会保留，而且会在此基础上新建一个提交。对于已经push到服务器上的内容做回滚，推荐使用revert。

 

 

下面是一个实际问题：

git checkout -- <path> doesn't do a hard reset; it replaces the working tree contents with the staged contents. git checkout HEAD -- <path> does a hard reset for a path, replacing both the index and the working tree with the version from the HEAD commit. 

 

一些总结：

A "hard reset" for a path is just done with git checkout HEAD -- <path>. A soft reset for a path doesn't make sense. A mixed reset for a path is what git reset -- <path> does.