A piece of Git
本文主要是对git-scm上的一篇博客的总结与补充,有说的不清楚的地方希望读者能读一下原博客
git的三个空间
在设计上,git将传统的工作空间,也就是工作目录,划分为三个层次:
Paste_Image.png由右往左分别为:工作目录,暂存区和版本库。中文翻译版本众多,我们就用它的英文版本好了。那么,平时我们工作于Working Directory,作出一部分修改后,我们会git add
来将我们的修改暂存,也就是加入Index,最后使用git commit
完成一次提交,也就是将当前Index中的文件加入到版本库,并移动HEAD指针指向当前提交。如下图:
git reset
git reset
指令主要用来恢复文件,撤销提交。
对整个工程使用reset
不指定特定文件时,git reset
指令会进行如下3步操作:
- 修改HEAD(与其指向的分枝)指针,让它(们)指向指定版本。这一步reset了版本库,仅影响到HEAD(与其指向的分枝)指针。
- 用指定版本的工程文件还原Index区。
- 用指定版本的工程文件还原Working Directory。
而git reset
命名后面带的三种参数则分别表示reset过程进展到上面的三个阶段:
指定文件的reset
既然指定了reset特定文件,那就说明使用者的意图不在于修改版本库,因此指定文件的reset命令都不会执行阶段1,也就是不会修改HEAD指针。实际上在指定文件的情况下,reset指令只会用版本库中指定版本的文件还原Index区。
例子 实际应用:撤销git add的影响git checkout
git checkout
在功能上与reset命令很相似,但是二者确实是被设计用于不同场合的,下面来讨论它们的区别。
不指定文件的checkout
效果上,不指定特定文件,git checkout
与git reset --hard
几乎完全一样,区别在于:
-
git checkout
在对Working Directory进行“安全检查”。它会尝试对你当前Working Directory中的文件与指定checkout的版本进行一次简单合并,如果在运行git checkout
之前,你改动了工作区的文件,checkout操作不会覆盖你当前修改过的文件;而git reset --hard
操作则仅仅简单粗暴的覆盖整个工作区。所以git checkout
操作是安全的。 - 我们知道HEAD作为头指针实际上指向了版本库当中的分支指针,而分支指针才实际的指向某次提交,比如
HEAD->master->8bcea
这种结构。git reset --hard
命令实际是修改了上面例子中的master分支指针的指向;git checkout
命令修改的则是HEAD指针的指向:
因此,checkout更多的用于分支切换等非破坏性操作,而reset则用于还原等破坏性操作。
指定文件的checkout
有没有觉得刚刚在讨论指定文件的reset操作时,似乎漏了点功能?指定文件的reset只还原了Index区,可是如何还原Working Directory?是的,指定文件的checkout操作可以还原当前工作目录。
也就是说,可以简单的理解为,指定文件的git checkout
实现了指定文件的git reset --hard
操作,它首先用特定文件还原Index区,再还原Working Directory。
git revert
git revert
命令可以被认为是安全的reset操作。它会用指定版本的版本库状态在当前的HEAD指针后面添加一个提交,并移动HEAD指针。
也就是说,git会取出你指定的版本,“覆盖”你的Working Directory,然后执行:
git add .
git commit -m "Revert xxx"
这个操作的安全性在于:
- 不像reset那样有可能修改提交历史,而是增加了提交,符合git的设计思想,可逆操作。
- “覆盖”Working Directory的过程与checkout指令类似,会进行安全检查。
下面是一个例子:
Revertgit rm
*nix的软件思想有一条是不做重复的工作,因此git rm
与/bin/rm
功能是不同的:
- 默认情况下,
git rm
会讲文件同时从版本库、Index和Working Directory删除 - 加上
--cached
参数时,rm操作会保留Working Directory中的文件,而将其它两个区域中的指定文件删除。
而删除文件操作在git中也有安全限制,因此,如果Index或Working Directory中的指定文件与版本库中的校验和不一致,git rm
操作就会报错,而-f
参数可以指定强制删除。