#软件构造作为版本控制工具的git的一些理论知识

最新推荐文章于 2021-06-23 00:55:52 发布

FZQuantum

最新推荐文章于 2021-06-23 00:55:52 发布

阅读量292

点赞数

分类专栏：软件构造文章标签： git 软件开发

本文链接：https://blog.csdn.net/Franklins_Fan/article/details/106895131

版权

软件构造专栏收录该内容

33 篇文章 3 订阅

订阅专栏

我们平时使用git很多时候只是拿来主义的用一下，而不一定了解其背后的原理和设计思想，今天系统性的对其进行总结

文章目录

一张图描述
上图描述了git指令和其操作对象之间的关系

git的组成部分

从图中可以看到，git主要由三个部分组成：

工作目录（Workspace ）：本地文件系统
暂存区（ Staging area ）：隔离工作目录和Git仓库
本地的CMDB （Local repository ）：本地的CMDB ，通常是一个 .git 目录
远程的CMDB （Remote repository ）：和本地CMDB对应的远程目录

而git管理下每个文件将会属于一下三个状态中：
已修改（Modified ）已修改的文件在工作目录中，和其在git版本库中的文件不同，尚未加入到暂存区
已暂存（Staged ）已修改的文件已加入到暂存区
已提交（Committed）已修改的文件同步到git版本库中

他们之间的关系可由下图所示：

git中的Object Graph——版本之间的演化关系图

Object Graph：版本之间的演化关系图，一条边 A->B表征了“在版本B的基础上作出变化，形成了版本A”
在这里插入图片描述
git的历史记录图中的每个节点表示项目的一个提交版本（也称为修正版本）：都是当时所有文件的完整快照。

每个commit指向一个父亲
多个 commit指向同一个父亲：这些子节点是从父节点中先前共同版本的分支
一个commit 指向两个父亲：两个父节点合并的结果

一个分支（branch ）只是指向一个提交节点的名称
而头节点指针（HEAD）指向当前的最新的提交节点

我们需要记住正在修改的分支。因此HEAD指针指向当前的提交节点

对于git中每一个提交节点

在这里插入图片描述

每一个提交节点指向具体文件存储的指针，Git文件系统允许不同的提交节点共用一个实际文件，即与之前commit 中未发生变化的文件，因此无需重复存储。
文件未发生变化，则后续多个版本始终指向同一个文件，文件发生变化了，存储两份不同的文件，两个版本指向不同的文件
每个提交节点还储存有日志——谁，在什么时候，附带了什么消息

具体可如下图所示：
在这里插入图片描述

git中的分支与合并

**分支（branch ）**是版本控制对象的副本，因此可以沿两个分支并行进行修改而相互不受影响
合并（Merge） 是把两个分支合并到一起
举例说明：
对于某一个开发：
假设我们已经commit了 $C_0$ , $C_1$ , $C_2$ ,当前的master分支指向 $C_2$
在这里插入图片描述
此时，我们执行检出操作 git checkout –b iss53

就会创建出一个新的分支 iss53
在这里插入图片描述
然后在 iss53 上，我们再commit出一个节点 $C_3$

然后我们再checkout回原来的master节点
git checkout –b hotfix 创建一个新的hotfix分支，并commit一个 $C_4$

此时，如果想合并hotfix分支到master分支中，因为master分支指向hotfix分支的父节点，所以只需要将master分支指向的节点向后移即可
执行：git merge hotfix后
在这里插入图片描述
然后我们删除hotfix分支（git branch –d hotfix ），并切换回iss533分支（git checkout iss53 ），并commit一个新的节点，执行后结果如下图所示：

此时再换回master分支（git checkout master），尝试将 iss53分支合并进master之中
在这里插入图片描述