用git实现一次提交

昨天已经讲了如何创建本地仓库，以及如何开始用git来管理我们的文件。

一、git status及git init

现在我在我的本地仓库中存放了文件“9.9-9.14”，然后我们可以打开命令行【<win+R>→cmd】，接着用cd 文件名的方式进入为本地仓库创建的文件夹后，我们讲到可以用git status来查看当前仓库的状态，看下面的图片显示:not a git repository,这是因为我还没有初始化我的本地仓库即还未创建我的本地仓库

接着：我们可以

输入 git init实现对本地仓库的创建，就会出现

Initialized empty Git repository in C:/Users/waitw/Mydiary/.git/

此时我的文件夹里有.git这个隐藏目录，还有我即将要提交的文件

二、git add

在进行提交之前，要先把文件放进暂存区，暂存区允许我们针对特定的文件进行提交，可以提高提交的灵活程度。

输入git add .

<注：会出现warning可忽略，只是对行尾符的转换>

git commit

输入git commit -m 提交信息

提交信息一般你想对本次提交备注一些信息比如写“提交我这几天写的日记”，或者“我增加了新的特性”等。

之后我们可以通过查看日志来确认我们的提交是否成功

输入 git log

来解释一下上面的陌生名词：

首先是

• commit 019d99091e49a319970bf5dbb89004f2b5095e27：

  • 后面跟的数字指的是当前提交的唯一哈希值（commit ID）。每个提交都有一个唯一的哈希值。

  插入两个名词解释：

  哈希值：根据文件内容通过 SHA-1算法生成的一个唯一的短字符串。而字符串是啥的，是计算机中的数据类型，由字母、数字、符号、空格等组成，字符串通常用单引号或者双引号包裹起来。而SHA-1 呢，全称是Secure Hash Algorithm 1，它是一种加密哈希算法，可以将任意长度的输入比如一个文件的内容转换为一个40 位字符的字符串，即 160 位的哈希值，长度是固定的，并且就算文件内容只改变一个字符，SHA-1 算出来的哈希值也会完全不同。

  另外一个是数据结构，它是计算机中组织和存储数据的方式，就像是一个容器来存放数据的，并且这个容器是有特殊的形状的。如git中组织和存储数据的其中一种方式就是为每一次提交都创建一个“提交对象”，暂且把它想象成一个大碗，有自己个性的碗，而哈希值根据提交的内容计算出来标识提交对象，所以每个提交对象都有一个哈希值，且唯一，哈希值可以理解为它的身份证号，假如这个碗有身份证号哈，那这个碗都装着些啥呢？

  • 作者信息：是谁编写了这次改动（包括姓名、电子邮件和时间）。
  • 提交者信息：是谁执行了这次提交操作，通常呢提交者和作者是同一个人。
  • 提交时间：记录提交的具体时间。
  • 提交说明：提交时填写的描述，通常是关于改动的简短说明。
  • 本次提交的内容：保存这次提交中所有文件的状态。

  为什么是文件状态？考考你，因为我们昨天说了既然git不选择每次都提交文件内容，那必然要有另外一种提交方式，即保存的是文件的状态，怎么理解这个文件状态：假如你有一个代码，第一次你写的是

  Hello, World!

  后面你改成

  Hello, Git!

  因为文件进行了改动，所以前后文件的哈希值会发生改动，也就是文件的状态发生了改变。

  所以提交对象中包含的这次提交中所有文件的状态用哈希值来表示是最合适不过的了。

  假设文件有以下目录：

  Mydiary/

• ├── fileA.txt

• └── folderB/

•                     ├── fileB1.txt

• └── folderC/

•                      └── fileC1.txt

  如果把Mydiary看做是一棵树的主干，那fileA就是第一个冒头的枝丫，注意它不是一个新的目录，即它没有再生出分支；而folderB是第二个冒头的枝丫，同时它生出了分支，即fileB1,注意fileB1没有生出分支；第三个冒头的枝丫是folderC，它跟folderB一样也生出了分支，即fileC1，同样的fileC1也没有生出分支。

  针对这些枝丫和枝丫的分支git也有专门的数据结构去“存放”它。没有再长出分支的如fileA.text 和fileB1.text以及fileC1暂且称为文件条目，会被描述成blob对象，是git最小的数据结构，可以理解成就是最小的碗，而有分支的folderB和folderC暂且称为子目录条目，则会被描述成树对象，其实整个Mydiary就是一个树对象，子目录是它的子树对象。

  那接下来就来看看它们对应的哈希值是怎么计算的？

  文件条目哈希值的计算：仅仅根据文件内容来计算，我们会称它为“指向blob对象的哈希值”

  子目录条目哈希值的计算：那目录的哈希值计算根据那些内容呢？先看里面包含什么，没错它还是有包含文件条目，即会根据指向blob对象的哈希值、还有其文件名、文件的基本权限如读、写、执行。所有这些打包然后被计算成我们所称的：”指向树对象的哈希值”，因为别忘了子目录用树对象来描述。同样地，所以我们的总目录Mydiary的哈希值就可以根据文件条目的：指向blob对象的哈希值和其文件名、文件的基本权限，以及子目录条目的：子目录名及指向子目录的树对象的哈希值来计算；如下：

  1. 文件条目：
     • 文件权限
     • 文件名
     • 指向文件内容的 blob 对象的哈希值：指向文件内容的哈希值。
  2. 子目录条目：
     • 子目录名
     • 指向子目录的树对象的哈希值

  注意：

  ① 是基本权限但并不是详细的文件权限设置，而是一个简化的标识。

  ②执行包括运行程序、脚本、服务或批处理任务来完成计算、自动化操作、启动服务和执行重复性工作。 ③如果子目录条目里面还有子目录那就按照目录条目哈希值的计算方法去计算就好了。

• (HEAD -> master)：

  • HEAD 是一种工作指针，它在哪，就说明你当前正在哪里进行操作，比如这里指向master，意思就是当前在master这个分支上进行操作，即我们正在master这个分支上进行提交。

• Author: Potter <waitwhat5656@163.com>：

  • 这是我提交的作者信息，包括姓名和电子邮件地址。

• Date: Sun Sep 15 14:05:40 2024 +0800：

  • 这是我提交的日期和时间。日期格式为 Weekday Month Day Time Year Timezone。

• 备份我9月9号到14号的日记：

  • 这是我在提交时输入的提交信息。

好了，解释完这些名词之后，我们明天继续学习git 接下来的操作，也就是当我们对文件进行二次提交的时候会发生什么？还有如果我们想撤回某个在暂存区的文件该如何撤回呢？还有什么情况下会用到git的创建分支以及合并分支呢？预知后事如何，且听下回分解~