版本控制系统之apache
一、简介
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 gitLoaded 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 -s100644 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 logcommit 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 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 加上仓库地址进行克隆
提示:可以看到克隆成功后,本地就会和远端仓库一模一样的文件结构的目录;
以上是 版本控制系统之apache 的全部内容, 来源链接: utcz.com/a/56967.html