Git基础

最新推荐文章于 2023-05-07 16:52:42 发布

Claude的羽毛

最新推荐文章于 2023-05-07 16:52:42 发布

阅读量243

点赞数 1

分类专栏： Git 文章标签： git

本文链接：https://blog.csdn.net/xcinkey/article/details/121082341

版权

Git 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

人人都听过Git，但不一定人人都用得到Git。好多人用了Git，但是也不清楚自己用到的是哪个Git。好多人觉得自己懂Git，但是实际上自己是个shit。那么，Git到底是个什么shit？

Git是什么

直接上搜索引擎搜这个问题的话，大部分简洁的回答是：Git是一个VCS（version control system，版本控制系统）。

那么什么又是版本控制？

这里引用书中原文“版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统”。而这里说的这个“文件”并不限定于代码文件，而是泛化到任何类型的文件。但是依旧不太好理解，什么叫“查阅版本修订情况”？

想象我们在没有这个什么乱起八糟VCS的情况下是如何管理文件的：我做了一个游戏项目出来，老板要我改个操作方式，我一通码代码，完成了，可是我这个时候要考虑——要是某天老板要我把操作方式改回原先的怎么办？好的，我找个硬盘把原先的版本存起来，然后把改了之后的版本再存起来，这样我自己就可以随时在这两个项目上进行切换了，这样我就依靠我的脑袋作为核心实现了一套VCS，不过代价就是需要靠脑袋（或者其他方式）记住我把其中哪一个版本存在了哪一个位置，而且硬盘占用方面更是往往要成倍得增加。

这个时候某些“笨人”说：“我记不住怎么办？”于是他们就用更“聪明”的计算机作为核心，开发出一套又一套的VCS，来帮助他们进行这个分配和访问的操作（当然现代VCS的功能已经远不止于此了）。在这种背景下，把VCS称为是“多版本辅助备份系统”似乎更为合适。我们可以为每一个版本标注一个日期以和其他版本区分开，这样起码在不打开工程浏览的情况下，也可以快速识别出这到底是哪一个版本。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iGMfaqDE-1635754235738)(C:\Users\jinyuan\AppData\Roaming\Typora\typora-user-images\image-20211027184138101.png)]$

LVCS（local version control system，本地版本控制系统）

可是我们上面的那个方法虽然简单，还是实在是太废内存了而且老容易搞错，做一个版本内存占用上就得多加一份，加入一个项目文件1个g的话，100个版本就要100个g，那谁受得了。于是人们开始思考改良的方案，比如RCS（reversion control system，回退控制系统），它不再完整地保存每个版本，而是去记录版本与版本之间的差异（在RCS里称为是补丁），然后通过应用补丁，来完成版本的回退。

到目前为止，我们都是在讨论一个人自己如何去完成工作，现在稍微拓展一点，如何让多个端上的人们协同工作起来，即多个端同时使用这个“多版本辅助备份系统”。

CVCS（centralized version control system，中心化版本控制系统）

其实有了前面的基础，这个CVCS也就不难理解了，就是把我们前面说的用来存储版本的“硬盘”来通过网络链接到各个端上，让所有人都能够访问到。人们都能够取出别人上传的最新的文件或者把自己的更新提交上去来让别人能够看到。好处是比较明显的，所有人都能够协同起来，看到别人进度的同时把自己的进度也按照意愿公布出去，可是这种“中央集权”式的系统也是有着相应的弊端。想象一下如果这个中央服务器宕机了，或者数据磁盘损坏了，那可就是所有协同的人都需要等待中央的修复而无法工作。最简单的解决方案也显而易见，还是备份，启用备用服务器，加载备份数据库，代价就是每一次提交去进行一次额外的备份。

当然，“笨人”想出了更聪明的办法。

DVCS（distributed version control system，分布式版本控制系统）

这个DVCS的问世一部分原因就是为了改进原先“中央集权”的状况，核心思路就是“分担压力，降低风险”，从原理上讲，就是每个客户端都对服务端做一个完整的镜像，我们每次从服务器上拉取项目到本地时，实际上都是对服务器的对应仓库做一次备份，这样在中央服务器故障时，可以从任意一个客户端进行快速得恢复，即人人都是服务端的备胎。

在这里插入图片描述

而Git，即是应用这个技术的佼佼者。

现在我们能够回答“Git是什么？”了吗？

还差一点，前面的是技术大框架，现在还缺亿点点细节，比如说版本与版本之间是如何快速切换的。

前面提到了RCS，引出了补丁的概念，即通过记录版本与版本间的差异，来进行快速的回退或者其他操作，比如说我想从版本3回到版本2，而我本地现在是版本3，那只要对当前这个版本应用这个差异补丁，存储的压力也只有一个版本外加多个差异补丁，这其实就是对**基于差异（delta-based）**的版本控制的粗浅解释（原文解释：以文件变更列表的方式存储信息，将存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异。）。

在这里插入图片描述

Git和其他VCS系统的差异也体现在这个地方，即看待数据的方式上（更具体一点，如何看待这一个又一个的版本，例如我们一开始用的那种硬盘保存法，就是把一个又一个的版本看作是一个个的文件夹，很粗暴得不去关心内里到底是什么文件）。这里Git自己用了一个快照（snapshot）的描述，即Git将一个个的版本看作是一系列的针对项目工程文件的快照。

Snapshot（快照）

我们来聊聊什么是快照，以及快照又是怎么服务于Git的版本控制的。假设我们现在已经上传（commit操作）好了一个版本，同时在之前的基础上又做了一些更改，此时进行第二次上传。这是Git就会帮我们来执行一次快照，具体就是：Git读取当前工作区的所有数据，进行一次数据预存，然后会用这个预存内容与上一次的最终快照进行一次比对，对于没有发生改变的文件，Git不会再重新存储一遍，而是用一个指针指向上一个版本中的对应数据，而发生了改变的数据就会进行保留，这样对整个文件夹进行了一次扫描及操作过后，这一版的快照就完成了。然后后面再有上传就会和这个版本的快照进行比对。

在这里插入图片描述

再进一步，从DVCS的角度触发，每个操作端（客户端）都有一份完整的快照拷贝，用户可以直接与本地的库进行交互，再将交互内容同步到服务器公布出去，这样一来，就将提交（或者说上传）这个操作的对象从网络转换到本地来执行，从而消除了网络延迟带来的操作延迟，使我们即便离线也可以做大部分的事情（当然从本地的仓库上传到服务器还是需要网络的，只不过这一步Git帮助我们在有网的时候做了，相当于是把我们和网络隔离开了）。

当然也有疑问：以快照这种模式来处理数据，会不会在某种情况下存在数据丢失的问题？

即数据完整性的问题，Git会用到SHA-1散列的机制来计算数据的校验和（猜测应该是类似哈希表的结构，利用文件的内容和目录结构通过哈希函数算出一个字符串），从而与文件建立起引用，这样的话，任何的修改和删除等操作都绕不过Git的监控。

以上，大概建立起对Git的一个整体性的认识，能够从理论上知道Git在做一件什么样的事儿，下面我们就来逐步地扣扣细节。

Git、GitLab、GitHub有什么区别

我们知道了Git用来做什么事，那么GitLab和GitHub又做了什么？

首先必须要明确的一点，Git不等于GitLab或者GitHub。就像计算机不等于Windows，移动通话技术不等于iphone等等。

GitLab和GitHub都是基于Web的Git仓库，提供代码托管的服务（包括由Git支持的版本控制以及相应的自己维护的仓库）。他俩的逻辑处理核心都是Git，互相之间的区别就有点像移动和联通的区别——收费规则、基站建设情况，对应到GitLab和GitHub就是仓库的收费规则，服务器的分布和数量等等。

在他们的帮助下，我们就不需要自己去建立自己的远程仓库，而可以直接使用他们提供给我们的仓库（开源项目免费，私人项目收费，具体规则参考两者的官网），然后由Git作为核心机制来进行版本控制。

更进一步，还有很多开发者做了一些图形化的界面，如SourceTree，GitHub Desktop，将仓库的配置、Git操作用图形化的界面、按钮等包装起来，将一些不友好的操作在后台自动帮我们做掉，只留给我们最直观的符合人的认知操作习惯的操作，这些是完全可以用Git的命令行语言替换掉的（当然，有好用的工具为什么不用呢，不需要为了装杯硬用原生Git命令行）。