运维入门之git服务器

git是linus为了管理Linux内核代码而设计的管理工具,成为目前最流行也是应用最为广泛的版本控制工具

git的基本结构

在这里插入图片描述

这张表格只是大概描述git的几个区域,在官网有一个动态的说明文档git的结构及命令

  • Workaspace:用户的操作空间,也就是我们编辑文档的目录
  • Index :索引区,git add之后,会在索引区建立文档的一个索引,也可以理解为暂存区或者缓冲区;
  • Repository:这里指的是本地的仓库,真正存储数据和索引的地方;
  • Remote Repository:远程仓库,实际中应用最多的一种。

git的工作原理

git版本控制是基于类似快照的方式存在,当文件内容不发生变化时,则只建立快捷,当文件内容发生变化时,则通过复制文件+变化内容=新文件;文件在Repository中的存在形式是文件对象(包括数据+数据位置等信息)的hash值存在;
简单过程也可以用如下图表示:
在这里插入图片描述

  • 当文件A发生变化,文件B不变,我们的工作目录依然是两个文件,git add之后,索引区会对文件A进行重新求hash值并记录,git commit(提交)之后,文件A会重新保存一份,而文件B只是创建一个链接指向新的HEAD
  • master则指向新的HEAD,此时HEAD值已经发生变化
  • 图中黑色提交表示蓝色提交的父提交

git的配置文件

git有三种配置文件

  • 仓库特有:.git/config (git config)
  • 全局配置:~/.gitconfig(git config --global
  • 系统配置:/etc/git/gitconfig(git config --system

git对象类型

  • Blob对象:文件的每个版本表现为一个BLOB文件,可以理解为文件的存在形式
  • tree对象:每一级目录便是树状结构的一个节点,索引中的对象commit之后则创建树对象
  • 提交对象:保存版本库一次变化的元数据,作者、日期、邮箱、日志等,每个对象都指定一个目录树对象
  • 标签对象:用于对一个特定对象一个已读的名称

git中的文件分类

  • 已追踪(tracked):使用git add命令添加至索引中的文件
  • 被忽略(igonre):在版本库中通过“忽略文件列表[./.gitigonre]”明确声明的文件,支持正则表达,在仓库的根目录;
  • 未追踪(untracked):除了以上两种的其他文件

git分支

在程序的编写提交过程中,可能涉及多个工作组同时对代码进行修改、提交,为此便出现了分支,其结构如图(一以下内容中黄色圆圈表示一个commit):
在这里插入图片描述

分支的命名规则:

1、可以使用“/”,但是不可以“/”结尾

2、不能以“-”开头

3、以位于“/”后面的组件,不能以“.”开头

4、不能使用连续的“.”;

5、不能包含空白字符;

6、不能使用^、~、?、*、[等正则意义的符号

7、必须唯一;

8、分支名字始终指向目标分支的最近提交

最简单的命令如下:
git branch [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]

git branch $BRANCHNAME $START-POINT
例如:实现上图中的分支结构
[root@localhost myproject]#git branch B1 B

例如:查看分支

[root@localhost myproject]# git branch -l
B1
* master

例如:切换到分支B1

[root@localhost myproject]# git checkout B1
Switched to branch ‘B1’
[root@localhost myproject]#git branch -l
* B1
master

这里有一个HEAD与master的概念,个人理解HEAD就如同一个指针函数,当你想回溯到哪个节点上,HEAD直接指向那个节点即可;而master则表示最近的一次commit(提交),可以用下图理解:
在这里插入图片描述

此时我们就切换到了分支B1的工作环境下,使用git cat-file -p HEAD便可看到B1的tree对象

GIT分支的合并(一)

正所谓“天下大势,分久必合”,分支势必有合并的一天,结构如下:
在这里插入图片描述

基本命令如下:
git merge -m <msg> $FRANCHNAME <commit>

这里就有两个概念“^”和“~”:

  • ~:以当前提交向前的父提交,例如:~1表示父提交1,~2表示父提交2(分支合并提交中,表示父提交2)
  • ^:以当前分支父提交递归,例如:^1~1表示父提交1的父提交

这样的表述可能更加模糊,从下图即可直观的看到两者之间的关系;
在这里插入图片描述

  • F(HEAD)的分支父提交仅且只有两个:E(HEAD^1)和D1(HEAD^2),这里1和2的顺序是根据master来的(递归父提交优先),此时如果你使用HEAD^3则会报错,因为没有其他的分支父提交
  • D(HEAD~2)是E(HEAD^1)master线上的递归父提交,则表示为HEAD~2或者HEAD~1~1或者HEAD^1~1
  • E(HEAD~1\HEAD^1)因为即是F(HEAD)的递归父提交,又是分支合并的父提交,则有两种表示方式,C(HEAD~3)同理也有两种表示方式

    当然最简单的方法就是git log --graph或者git log --graph --pretty=oneline --abbrev-commit查看整个tree对象,然后查看到每个commit对应的hash值,直接调用hash值即可

[root@localhost myproject]# git log --graph --pretty=oneline --abbrev-commit
*   f50cb1f Merge branch 'devel'
|\  
| * 6beff3e v0.0.2-3
* |   b9ffb4a Merge branch 'devel'
|\ \  
| |/  
| * 5af2c01 v0.0.2-2
| * f31763f v0.0.2-1
* | fb84fb7 v0.0.4
* | cb22d49 v0.0.3
|/  
* 2304fe2 v0.0.2
* 86777c6 v0.0.1

git分支合并(二)

分支合并除了merge这样的方式之外还有一种,叫做rebase。有人称此过程为变基,也有人称为衍合;下面从图例就可以看到主要区别:
在这里插入图片描述

上图是HEAD指向节点D时,分支B指向B2时,我们切换至B分支,然后将master从节点D rebase至分支B的B2节点上git rebase master,则就会出现如上的结果;rebase与merge不同就是缺少了一个节点,在现有分支上将数据取&;
此时可以解释为:删除原有分支B节点,临时保存原数据以补丁追加至节点D之后。可以通过查看前后的各节点的hash值来确定


[root@localhost myproject]# git checkout B
Switched to branch 'B'
[root@localhost myproject]# git rebase  master      
First, rewinding head to replay your work on top of it...
Applying: B1
Applying: B2
[root@localhost myproject]# git log --graph --pretty=oneline --abbrev-commit
* 5fddaec B2
* 0835079 B1
* b8dac7d D
* 3beae4e C
* 0cf96de B
* 906ba55 A
[root@localhost myproject]# git checkout master
Switched to branch 'master'
[root@localhost myproject]# git log --graph --pretty=oneline --abbrev-commit
* b8dac7d D
* 3beae4e C
* 0cf96de B
* 906ba55 A

没有更多推荐了,返回首页