一、简介
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安装
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
[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:查看暂存区中的文件列表
1
2
3
|
[root@node01 test ] # git ls-files -s 100644 a63efecf511676df4bf5b4a50e19c958f156f3c6 0 fstab [root@node01 test ] # |
git ls-files -o:把当前目录的文件同暂存区中的文件列表比较,列出未被追踪的文件;
1
2
3
4
5
6
7
|
[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:提交暂存区的文件到本地仓库
1
2
3
4
5
|
[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:查看提交日志
1
2
3
4
5
6
7
|
[root@node01 test ] # git log commit 6f8bf56578144cee9cf16539587fca5aaf61e3bc Author: tom <admin@admin.com> 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 diff HEAD:当前工作目录的文件同最近提交的文件做比较
提示:以上反馈告诉我们,当前工作目录中的password文件同最近提交(对象库)中的password比较,少了root:x:0:0:root:/root:/bin/bash这行数据,多了一个test;
git diff --cached:对比当前索引和最近一次提交做比较
提示:之所以索引和最近一次提交比较和当前目录的password同最近一次提交比较,结果相同;原因是我们只是添加到索引,并未提交,如果此时提交,那么当前工作目录的password文件就和索引和最近一次提交,三者都会相同;也就是运行git diff/git diff HEAD/git diff --cached的结果都是没有任何输出;
验证:提交暂存区的文件到对象库,然后再次比较
提示:可以看到提交以后,不管怎么比较都是相同的;
比较v3和v2的不同
提示:以上显示表示v3相比较v2少了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 加上仓库地址进行克隆
提示:可以看到克隆成功后,本地就会和远端仓库一模一样的文件结构的目录;