Git之管理修改与删除文件

首先，我们需要明白一个概念。Git之所以比其他版本控制系统设计得优秀，是因为Git追踪并管理的是文件的修改，而不是文件。那么，什么都算是文件的修改呢？添加内容，算修改；删除内容，也算修改；新增文件，算修改；删除一个文件，也算修改……但是我们怎么来确认Git是对修改的管理而非文件的呢？

管理修改

我们还以之前的文件demo.txt为例，修改其中的内容，增加一行内容：

然后添加到暂存区，并查看状态：

 

之后，再对其进行一次修改，继续添加一行内容：

然后，提交到分支上：

 

之后，查看状态：

 

仔细观察后，我们发现，第二次的修改并没有提交到分支上。但是我们明明已经做了修改的啊，为什么没有被提交呢，难道Git管理的不是修改吗？其实并不是，真正的原因是，Git管理的确实是修改没错，但是只有添加到暂存区的修改才算修改，而没有添加到暂存区的修改就算不上真正意义上的修改，所以Git才没有将第二次修改提交。仔细回顾一下我们对demo.txt文件的修改过程：第一次修改→git add→第二次修改→git commit，可以发现，我们并没有将第二次修改添加到暂存区，所以才导致第二次修改没有被提交，Git提交的时候只负责提交暂存区的修改。我们可以看一看工作区和版本库里的文件的区别：

 

可以看到，第二次修改确实已经完成，但是确实没有被提交。此时，如果我们想提交第二次修改的话可以像之前一样，先添加，然后再提交，不用担心第一次修改提交之后会影响到第二次的修改。

总结起来就一句话，只要修改没有被添加到暂存区，那么修改就不会被提交！

撤销修改

我们先将之前的第二次修改提交了。

如果我们在修改文件的时候写上了一些后来在检查的时候认为根本不需要的内容，那么这个时候我们就需要对修改进行撤销。比如，我们在demo.txt文件里添加了如下内容：

此时，我们想把最后一行的内容删除掉。那我们可以直接手动删除最后一行的内容，即手动将文件回退到上一个版本。之后我们查看一下状态：

 

发现，Git指示我们使用git checkout命令来放弃对工作区的修改。

 

执行之后，我们查看一下文件内容，发现其实已经回退了。

 

命令git checkout -- demo.txt意思就是把demo.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是demo.txt自修改后还没有被添加到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是demo.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

git checkout -- demo.txt命令中的 -- 其实相当重要，如果没有这个 -- ，那么这个命令就变成了“切换到另一个分支”的命令了。

还有一种情况，如果我们对文件进行了修改，而且已经添加到暂存了，现在要从暂存区把这个文件的修改部分给撤销掉。假设还是之前的文件：

只不过现在这个文件已经到了暂存区了，不只在工作区存在了。但是呢，还没有被提交呢，此时我们先查看一下状态：

 

发现可以使用git reset命令来撤销掉暂存区的修改，并重新放回到工作区，于是

 

git reset命令不仅可以回退版本，也可以把暂存区的修改回退到工作区，此时，查看状态：

 

暂存区是干净的，工作区有修改。之后，我们只需要按照之前的方法丢弃掉工作区的修改即可：

 

总结：

场景1：当改乱了工作区某个文件的内容，想直接丢弃掉工作区的修改时，用命令git checkout命令

场景2：当不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，那就版本回退，不过前提是没有推送到远程库。

删除文件

之前说过，在Git中，删除其实也是一种修改操作。比如我们现在想删除test.txt文件，一般情况下，我们可以直接使用rm命令来进行文件的删除。

 

但是在Git中，如果们使用rm命令删除了文件之后，Git会告诉我们工作区和版本库不一样了：

 

此时，如果我们真的想要从版本库中删除文件，那么就使用git rm命令来删除，并且记得commit。

 

之后，文件就从版本库中被删除了。如果我们不小心把文件删错了，此时我们还没有提交呢，那么我们就可以用checkout命令来把误删的文件恢复到最新版本。

 

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。同时需要注意的是，没有被提交到版本库里的文件被删除之后，是不能恢复的！！！