Git—文件添加查看删除修改

目录

1.添加文件—场景一

2.查看.git文件

3.添加文件—场景三

4.修改文件

5.版本回退

6.撤销修改

7.删除文件

---

1.添加文件—场景一

在包含.git的目录下新建?个ReadMe文件，我们可以使用?git add 命令可以将文件添加到暂存
区：

●添加一个或多个文件到暂存区: git add [file1] [file2]
●添加指定目录到暂存区，包括子目录: git add [dir]
●添加当前目录下的所有文件改动到暂存区: git add

●添加一个或多个文件到暂存区: git add [file1] [file2]
●添加指定目录到暂存区，包括子目录: git add [dir]
●添加当前目录下的所有文件改动到暂存区: git add

注意git commit 后面的-m选项，要跟上描述本次提交的message,由用户自己完成，这部分内
容绝对不能省略，并要好好描述，是用来记录你的提交细节，是给我们人看的。
例如:

git commit命令执行成功后会告诉我们，1个文件被改动(就是我们新添加的ReadMe文件)，插入了两行内容(ReadMe有 两行内容)。
我们还可以多次add不同的文件，而只commit 一次便可以提交所有文件，是因为需要提交的文件是通通被add到暂存区中，然后一次性commit暂存区的所有修改。如:

截至目前为止，我们已经更够将代码直接提交至本地仓库了。我们可以使用git log命令，来查看
下历史提交记录:

该命令显示从最近到最远的提交日志，并且可以看到我们commit时的日志消息。
如果嫌输出信息太多，看得眼花缭乱的，可以试试加.上--pretty=oneline参数:

需要说明的是，我们看到的一大串类似23807c5... 56eed6的是每次提交的commit id (版本
号)，Git的commit id不是1, 2, ....递增的数字，而是一个SHA1计算出来的一个非常大的数
字，用十六进制表示(你看到的commit id 和我的肯定不一样，以你自己的为准)。

2.查看.git文件

先来看看我们的. git的目录结构:

1. index就是我们的暂存区，add后的内容都是添加到这里的。
2.HEAD就是我们的默认指向master分支的指针:

而默认的master分支，其实就是:

打印的23807c536969cd886c4 fb624b997ca575756eed6是什么东西呢?保存的就是当前最新
的commit id 。
3. objects 为Git的对象库，里面包含了创建的各种版本库对象及内容。当执行git add命令
时，暂存区的目录树被更新，同时工作区修改(或新增)的文件内容被写入到对象库中的一个新的
对象中，就位于".git/objects"目录下，让我们来看看这些对象有何用处:

查找object时要将commit id分成2部分，其前2位是文件夹名称，后38位是文件名称。
找到这个文件之后，一般不能直接看到里面是什么，该类文件是经过sha (安全哈希算法) 加密过的
文件，好在我们可以使用git cat-file 命令来查看版本库对象的内容:

其中，还有一行tree 830a8c9fee fbdc098bbae2cdc25e5034ce1920d7，我们使用同样的方法，看看结果:

在看ReadMe对应的9c9e1f0f6bf f3015df71a0963004476f5e6cfd54 :

总结一下，在本地的git仓库中，有几个文件或者目录很特殊
????????index: 暂存区，git add后会更新该内容。
????????HEAD:默认指向master分支的一个指针。
????????refs/heads/master: 文件里保存当前master分支的最新commit id。
????????objects:包含了创建的各种版本库对象及内容，可以简单理解为放了git维护的所有修改。

3.添加文件—场景三

学习到这里，我们已经清楚了如何向仓库中添加文件，并且对于工作区、暂存区、版本库也有了一定的认识。那么我们再展示一种添加文件的场景，能加深对工作区、暂存区、版本库的理解，示例如下:

提交后发现打印了1 file changed, 0 insertions(+)， 0 deletions(-) ，意思是只有一个文件改变了，这时我们提出了疑问，不是新增了两个文件吗?
再来回忆下，git add是将文件添加到暂存区，git commit 是将暂存区的内容添加到本地仓库
中。由于我们并没有使用git add file5, file5 就不在暂存区中维护，所以我们commit的时候
其实只是把已经在暂存区的file4提交了，而遗漏了工作区的file5。如何提交file5呢?很简单，再次
add，commit即可。

4.修改文件

Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。
什么是修改?比如你新增了一行,这就是一一个修改,删除了一-行，也是一一个修改,更改了某些字符,也是一个修改，删了一些又加了一些，也是一一个修改，甚至创建一个新文件，也算一个修改。让我们将ReadMe文件进行一次修改:

此时，仓库中的ReadMe和我们工作区的ReadMe是不同的，如何查看当前仓库的状态呢? git
status命令用于查看在你上次提交之后是否有对文件进行再次修改。

上面的结果告诉我们，ReadMe被修改过了,但还没有完成添加与提交。
目前，我们只知道文件被修改了，如果能知道具体哪些地方被修改了，就更好了。有同学会说，我刚改的我知道呀!可是，你还记得你三天前写了什么代码吗?或者没写?

git diff [file] 命令用来显示暂存区和工作区文件的差异，显示的格式正是Unix通用的diff格式。也可以使用git diff HEAD -- [file] 命令来查看版本库和工作区文件的区别。
知道了对ReadMe做了什么修改后，再把它提交到本地仓库就放心多了。

git add之后，就没有看到上面no changes added to commit (use "git add"and/or "git commit -a") 的消息了。接下来让我们继续git commit 即可:

5.版本回退

之前我们也提到过，Git 能够管理文件的历史版本，这也是版本控制器重要的能力。如果有一天你发现之前前的工作做的出现了很大的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退的功能了。
执行git reset 命令用于回退版本，可以指定退回某一次提交的版本。要解释一下“回退”本质是
要将版本库中的内容进行回退，工作区或暂存区是否回退由命令参数决定:

git reset命令语法格式为: git reset [--soft | -- mixed | --hard] [HEAD ]
●--mixed为默认选项，使用时可以不用带该参数。该参数将暂存区的内容退回为指定提交版本内
容，工作区文件保持不变。
●--soft参数对于工作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
●--hard 参数将暂存区与工作区都退回到指定版本。切记工作区有未提交的代码时不要用这个命
令，因为工作区会回滚,你没有提交的代码就再也找不回了，所以使用该参数前一定要慎重。

HEAD说明:
可直接写成commit id,表示指定退回的版本
HEAD表示当前版本
HEAD^上一个版本
HEAD^^上.上一个版本
以此类推. ..
可以使用~数字表示:
HEAD~0表示当前版本
HEAD~1上一个版本
HEAD~2上上一个版本
以此类推..

为了便于表述,方便测试回退功能，我们先做一些准备工作: 更新3个版本的ReadMe,并分别进行3
次提交，如下所示:

现在，如果我们在提交完version3后，发现version 3编写错误，想回退到version2,重新基于
version 2开始编写。由于我们在这里希望的是将工作区的内容也回退到version 2版本，所以需
要用到--hard参数，示例如下:

我们惊奇的发现，此时ReadMe文件的内容，已经回退到version2了，当前，我们再次用git
log查看一下提交日志，发现HEAD指向了version2， 如下所示:

到这里一般回退功能就演示完了，但现在如果我后悔了，想再回到version 3怎么办?我们可以继续使.用git reset命令，回退到version 3版本，但我们必须要拿到version 3的commit id去指定回退的版本。但我们看到了git log 并不能打印出version 3的commit id，运气好的话我们可以从终端上去找找之前的记录，运气不好的话commit id已经被我们搞丢了
Git还提供了一个git reflog 命令能补救一下，该命令用来记录本地的每一次命令。

这样，你就可以很方便的找到你的所有操作记录了，但d95c13f这个是啥东西?这个是version?
3的commit id的部分。没错，Git版本回退的时候，也可以使用部分commit id来代表目标版本。示例如下:

可往往是理想很丰满，现实很骨感。在实际开发中，由于长时间的开发了，导致commit id早就找
不到了，可突然某一天， 我又想回退到version3,那该如何操作呢?貌似现在不可能了

值得说的是，Git 的版本回退速度非常快，因为Git在内部有个指向当前分支(此处 是master)的
HEAD指针，refs/heads /master文件里保存当前master分支的最新commit id。当我们在回退版本的时候，Git 仅仅是给refs/heads/master 中存储一-个特定的version,可以简单理解成如下示意图:

6.撤销修改

如果我们在我们的工作区写了很长时间代码，越写越写不下去，觉得自己写的实在是垃圾,想恢复到上一个版本。
情况一:对于工作区的代码，还没有add
你当然可以直接删掉你目前在工作区新增的代码，像这样:

辛亏我们工作效率不高，才写了一行代码就发现不行了，要是你写了3天，一直都没有提交，该怎么删掉呢?你自己都忘了自己新增过哪些，有同学说，我可以git diff xxx一下，看看差别在删啊，
那你肯定又要花3天时间删代码了，并且很大的概率还会改出bug。一周过去了，你怎么向你的老板交代呢?
Git其实还为我们提供了更好的方式，我们可以使用git checkout -- [file] 命令让工作区的文件回到最近一次add或commit 时的状态。要注意git checkout -- [file] 命令中的很重要，切记不要省略，一旦省略，该命令就变为其他意思了，后面我们再说。示例如下:

情况二:已经add，但没有commit
add后还是保存到了暂存区，怎么撤销呢?

让我们来回忆一下学过的git reset 回退命令，该命令如果使用--mixed 参数，可以将暂存区的内容退回为指定的版本内容，但工作区文件保持不变。那我们就可以回退下暂存区的内容了! ! !
示例如下:

用git status查看一下，发现现在暂存区是干净的，工作区有修改。

还记得如何丢弃工作区的修改吗?

通过这样的策略就恢复了

情况三:已经add ,并且也commit了
不要担心，我们可以git reset --hard HEAD^ 回退到上一个版本!不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。还记得Git是分布式版本控制系统吗?我们后面会讲到远程版本库，一旦你推送到远程版本库，你就真的惨了.....

7.删除文件

在Git中，删除也是一个修改操作，我们实战一下，如果要删除file5文件，怎么搞呢?如果你这样
做了:

但这样直接删除是没有用的，反而徒增烦恼，git status 命令会立刻告诉你哪些文件被删除了:

此时，工作区和版本库就不-致了,要删文件，目前除了要删工作区的文件,还要清除版本库的文件。

一般走到这里，有两种可能:
????????●确实要从版本库中删除该文件
????????●不小心删错了
对第二种情况，很明显误删，需要使用git来进行恢复，很简单我们刚学过(删除也是修改) :

对于第一种情况，很明显是没有删完，我们只删除了工作区的文件。这时就需要使用git rm将文
件从暂存区和工作区中删除，并且commit? :

现在，文件就从版本库中删除了。