版本控制系统之git
一、简介
git是Linux内核项目发起者linus用C语言写的，主要用来做项目的版本控制追踪；git是无中心节点的分布式版本控制系统，也是目前很流行的版本控制系统；其安装简单，使用简单；相比传统的cvs和svn，git要比前两者都要方便，前两者是有中心节点的版本控制系统，有中心节点就意味着，每次提交代码都得连接到中心节点（仓库），然后才能提交代码，提交代码（项目）依赖网络；而git在没有网络的情况下也支持提交代码到本地的对象库中；这样一来使得git使用非常方便；
git整体架构
提示：以上是git的一个大概的工作逻辑图，git版本控制系统主要由本地工作空间，本地仓库和远程仓库三部分组成；本地工作空间中包含本地仓库，本地仓库中主要有索引和对象库；用户在本地空间初始化一个项目，就相当于在本地创建了一个本地git仓库，其表现形式上在用户的工作目录下有一个.git的隐藏目录；用户要把本地的文件提交到远程仓库，首先得将文件添加到本地仓库中的索引中去，然后再把索引中的内容提交到本地对象库中存储；然后再从本地push一份到远程仓库；用户提交项目到远程仓库的过程就是这样；当然用户从远程仓库可以直接克隆远程仓库到本地；
git本地仓库结构
提示：本地git仓库主要由工作目录、索引和对象库组成；在用户执行git init后，就把对应的工作目录初始化为git本地仓库；
git add 在本地仓库中的表现
提示：以上表示用户执行git后，在本地仓库中的表现；用户在工作目录里有绿蓝两个文件，在执行git add后，它会在索引（暂存区）生成对应文件的索引信息，其索引主要记录文件的hash码和对应在对象库中的文件一个关联关系；这样一来git就可以追踪这两个文件的变化；如果此时我们在工作目录中继续编辑这两个文件，后续我们想知道我们编辑了那些内容，就可以把工作目录中的文件同对象库中的文件做对比；工作目录中的文件和对象库中的文件不同的是，在工作目录中的文件表现为两个正常的文件名，而在对象库中，这两个文件的文件名不再是工作目录中的文件名，而是把对应文件的内容做hash以后，把hash码当作文件的名称；
git commit在本地仓库的表现形式
提示：在用户把工作目录中的文件add到暂存区以后，如果执行git commit，git会在对象库中生成一个索引的快照文件（对象库中的黄三角）和一个提交对象（紫红色圆形）；提交对象中主要保存了对应的索引快照是什么时候床架的，对应提交指向的那个索引快照，项目的版本等等；上面我们说了索引中主要保存文件和对象库中的文件的关联关系，如果此时我们把工作目录中的文件删除以后，可以通过对象库中的文件进行恢复；其实在执行git add以后，把对应工作目录中的文件删除以后，都可以从对象库中找回；以上就是用户把工作目录中的文件提交到git在本地仓库中的一个工作流程；如果后续我们再次add 工作空间的文件到本地仓库也是一样的逻辑；
提示：当用户第二次提交时，在对象库中会生成第二个索引快照和提交对象；并且HEAD指针会指向当前才生成的提交对象；这样一来在对象库中就存在多个提交对象，如果此时我们需要恢复到某个版本，可以直接把head指针指向对应的提交对象即可；
二、git安装
[root@node01 ~]# yum install git Loaded plugins: fastestmirror base | 3.6 kB 00:00:00 epel | 4.7 kB 00:00:00 extras | 2.9 kB 00:00:00 updates | 2.9 kB 00:00:00 (1/2): epel/x86_64/updateinfo | 1.0 MB 00:00:00 (2/2): epel/x86_64/primary_db | 6.9 MB 00:00:01 Loading mirror speeds from cached hostfile * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.com Resolving Dependencies --> Running transaction check ---> Package git.x86_64 0:1.8.3.1-23.el7_8 will be installed --> Processing Dependency: perl-Git = 1.8.3.1-23.el7_8 for package: git-1.8.3.1-23.el7_8.x86_64 --> Processing Dependency: rsync for package: git-1.8.3.1-23.el7_8.x86_64 --> Processing Dependency: perl(Term::ReadKey) for package: git-1.8.3.1-23.el7_8.x86_64 --> Processing Dependency: perl(Git) for package: git-1.8.3.1-23.el7_8.x86_64 --> Processing Dependency: perl(Error) for package: git-1.8.3.1-23.el7_8.x86_64 --> Running transaction check ---> Package perl-Error.noarch 1:0.17020-2.el7 will be installed ---> Package perl-Git.noarch 0:1.8.3.1-23.el7_8 will be installed ---> Package perl-TermReadKey.x86_64 0:2.30-20.el7 will be installed ---> Package rsync.x86_64 0:3.1.2-10.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ========================================================================================================================== Package Arch Version Repository Size ========================================================================================================================== Installing: git x86_64 1.8.3.1-23.el7_8 updates 4.4 M Installing for dependencies: perl-Error noarch 1:0.17020-2.el7 base 32 k perl-Git noarch 1.8.3.1-23.el7_8 updates 56 k perl-TermReadKey x86_64 2.30-20.el7 base 31 k rsync x86_64 3.1.2-10.el7 base 404 k Transaction Summary ========================================================================================================================== Install 1 Package (+4 Dependent packages) Total download size: 4.9 M Installed size: 23 M Is this ok [y/d/N]: y Downloading packages: (1/5): perl-TermReadKey-2.30-20.el7.x86_64.rpm | 31 kB 00:00:00 (2/5): rsync-3.1.2-10.el7.x86_64.rpm | 404 kB 00:00:00 (3/5): perl-Error-0.17020-2.el7.noarch.rpm | 32 kB 00:00:00 (4/5): git-1.8.3.1-23.el7_8.x86_64.rpm | 4.4 MB 00:00:00 (5/5): perl-Git-1.8.3.1-23.el7_8.noarch.rpm | 56 kB 00:00:00 -------------------------------------------------------------------------------------------------------------------------- Total 5.0 MB/s | 4.9 MB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : 1:perl-Error-0.17020-2.el7.noarch 1/5 Installing : rsync-3.1.2-10.el7.x86_64 2/5 Installing : perl-TermReadKey-2.30-20.el7.x86_64 3/5 Installing : perl-Git-1.8.3.1-23.el7_8.noarch 4/5 Installing : git-1.8.3.1-23.el7_8.x86_64 5/5 Verifying : git-1.8.3.1-23.el7_8.x86_64 1/5 Verifying : 1:perl-Error-0.17020-2.el7.noarch 2/5 Verifying : perl-TermReadKey-2.30-20.el7.x86_64 3/5 Verifying : perl-Git-1.8.3.1-23.el7_8.noarch 4/5 Verifying : rsync-3.1.2-10.el7.x86_64 5/5 Installed: git.x86_64 0:1.8.3.1-23.el7_8 Dependency Installed: perl-Error.noarch 1:0.17020-2.el7 perl-Git.noarch 0:1.8.3.1-23.el7_8 perl-TermReadKey.x86_64 0:2.30-20.el7 rsync.x86_64 0:3.1.2-10.el7 Complete! [root@node01 ~]#
三、git基本命令使用
git init 初始化一个空仓库
git add 把当前工作目录中的文件添加到暂存区
提示：以上命令表示把当前目录下的文件添加到暂存区；点表示当前目录，当然也可以使用*，也可以使用对应的文件名；
git ls-files -s:查看暂存区中的文件列表
[root@node01 test]# git ls-files -s 100644 a63efecf511676df4bf5b4a50e19c958f156f3c6 0 fstab [root@node01 test]#
git ls-files -o:把当前目录的文件同暂存区中的文件列表比较，列出未被追踪的文件；
[root@node01 test]# git ls-files -o [root@node01 test]# cp /etc/passwd . [root@node01 test]# git ls-files -s 100644 a63efecf511676df4bf5b4a50e19c958f156f3c6 0 fstab [root@node01 test]# git ls-files -o passwd [root@node01 test]#
git cat-file：查看文件内容
提示：-p是以美观方式显示文件内容；查看对象库中的文件，需要指定对象库中的文件名称，通过ls-files -s可以列出暂存区文件的列表，其中包含文件的权限信息，文件的hash名称，以及对应本地目录的文件名称；
git config：配置git环境
git的配置分三级，仓库特有，其配置文件放在REPONAME/.git/config；用户持有，也称为全局配置，这里的全局指某个用户的全局，其配置文件在用户的家目录下的.gitconfig，用–global来指定；系统持有，指本机所有用户的git通用配置，其配置文是/etc/gitconfig，用–system来指定；
示例：配置仓库持有配置的用户名和用户邮箱
提示：git标记一个用户是靠用户名和邮箱标记；当然在生产中使用git通常上面的用户名和邮箱都是真实有效的，以便后续项目上的问题可以通过邮箱进行交流和反馈；
验证：看看我们配置的user.name和user.email是否保存在当前仓库的.git/config文件中呢？
配置全局git环境
配置系统git环境
git hash-object：计算指定文件的hash码
提示：可以看到本地仓库中的fstab文件的hash码同对象库中的文件名一样；说明在对象库中的文件名就是把对应文件内容hash以后的hash码当作文件名；
git rm：删除工作目录中的文件，及索引中的映射；–cache表示只删除索引中的映射，当前工作目录的文件并不删除；
删除当前目录文件的同时，也删除索引中的对应关系
提示：直接使用git rm删除文件是删除不掉的，必须使用-f，-f表示强制删除文件和索引中的文件，–cache表示只删除索引中的文件，并不对应本地文件做删除操作；
git mv：改变工作目录中的文件名，及索引中的映射；
提示：更改文件名称，如果使用shell命令mv更改文件名称，git会认为更改后的文件名的文件是一个新文件；所以要想更改索引中的文件名称，需要使用git mv来更改；
git commit：提交暂存区的文件到本地仓库
[root@node01 test]# git commit -m "v1" [master (root-commit) 6f8bf56] v1 1 file changed, 22 insertions(+) create mode 100644 password [root@node01 test]#
git log：查看提交日志
[root@node01 test]# git log commit 6f8bf56578144cee9cf16539587fca5aaf61e3bc Author: tom <[email protected]> Date: Fri Oct 9 21:03:03 2020 +0800 v1 [root@node01 test]#
git diff：比较提交、索引及工作目录；
提示：git diff命令用来比较当前工作目录下的文件同本地对象库中的文件差异，上面显示结果表示，本地password文件相比对象中的password文件多了一个test；如果我们在把当前文件删除一点数据，它会告诉我们在当前目录的文件中少了某某数据；如下
删除本地文件中的一些数据，再做比较
提示：以上提示说本地文件相比对象库中的文件，少了root:x:0:0:root:/root:/bin/bash这行数据，多了一个test；
git reset：撤消此前的操作；–soft：将HEAD引用指向给定的提交，但不影响索引和工作目录；–mixed：将HEAD引用指向给定的提交，并将索引内容改变为指定提交的快照；但不改变工作目录；–hard：将HEAD引用指向给定的提交、将索引内容改变为指定提交的快照，并改变工作目录中的内容反映指定提交的内容；
提示：以上主要做了两个不同的版本提交，第一次提交有test1文件，其内容是version1以及issue文件；第二次提交首先删除了test1文件，然后创建了teset2文件，其内容为version2，并且把fstab文件一并提交了；
验证：将HEAD引用指向第一次提交，并不改变工作目录的文件情况和索引；
提示：–soft就相当于回到第一提交以后，第二次把文件添加到暂存区，并未做提交到状态；
验证：将HEAD指向v1，并将索引更改为v1，并不更改当前目录文件
提示：–mixed就相当于第一次提交以后，第二次还未添加到暂存区的情况；重新添加并提交就会把head指向当前提交的版本，并且把索引快照，指向最近的提交；
验证：将HEAD引用指向给定的提交、将索引内容改变为指定提交的快照，并改变工作目录中的内容反映指定提交的内容；
提示：–hard就相当于直接回到提交第一次时的状态；当然第一次到第二次提交的中间数据会全部丢失；
git clone：从远端仓库克隆目录到本地
示例：从github上克隆ansible-for-kubernetes到本地
复制远端仓库地址后，在本地使用git clone 加上仓库地址进行克隆
提示：可以看到克隆成功后，本地就会和远端仓库一模一样的文件结构的目录；
