参考:https://www.liaoxuefeng.com/wiki/896043488029600/897271968352576
Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。
工作区(Working Directory)
就是你在电脑里能看到的目录,比如我的learngit文件夹就是一个工作区:
版本库(Repository)
工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。
前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:
第一步是用git add
把文件添加进去,实际上就是把文件修改添加到暂存区;
第二步是用git commit
提交更改,实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。
可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。
一、俗话说,实践出真知。现在,我们再练习一遍,先对readme.txt做个修改,比如加上一行内容:
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
然后,在工作区新增一个LICENSE文本文件(内容随便写)。
①用git status
查看一下状态:
Git非常清楚地告诉我们,readme.txt被修改了,而LICENSE还从来没有被添加过,所以它的状态是Untracked
。
②现在,使用两次命令git add,把readme.txt和LICENSE都添加后,用git status再查看一下:
现在,暂存区的状态就变成这样了:
所以,git add命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执行git commit就可以一次性把暂存区的所有修改提交到分支:
一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的。现在版本库变成了这样,暂存区就没有任何内容了:
小结一:
暂存区是Git非常重要的概念,弄明白了暂存区,就弄明白了Git的很多操作到底干了什么。
关于管理修改:
为什么Git比其他版本控制系统设计得优秀,因为Git跟踪并管理的是修改,而非文件。
什么是修改?
比如你新增了一行,这就是一个修改,删除了一行,也是一个修改,更改了某些字符,也是一个修改,删了一些又加了一些,也是一个修改,甚至创建一个新文件,也算一个修改。
总结:每次修改,如果不先用git add到暂存区,那就不会加入到commit中。
关于撤销修改:
语句一:git checkout -- readme.txt
语句二:git restore readme.txt
(例如,将文件内容修改了两次 使用notepad编辑,在readme.txt中添加了一行:My stupid boss still prefers SVN.
若想将添加的这句删除且还没有git add至缓存区,以上二者语句选其一,如下图示。)
命令git checkout -- readme.txt
意思就是,把readme.txt文件在工作区的修改全部撤销,这里有两种情况:
一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit或git add时的状态。
以上是修改后没有进行git add操作,如何撤销修改。
接下来是修改后进行了git add操作还没commit,如何撤销修改?
语句一:git reset HEAD readme.txt
语句二:git restore --staged readme.txt
git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD时,表示最新的版本。
再用git status查看一下,现在暂存区是干净的,工作区有修改。
退到工作区后,在进行之前的丢弃工作区的修改:
然后发现readme.txt内容还原啦!
小结二:
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout – file。
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD ,就回到了场景1,第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。
本篇完,撒花!!