深刻了解版本控制的神秘-把握-原理-Git (深刻了解版本的英文)
前言
作为一个新时代的开发者，想必大家在上班中，有一样物品是和大家「如影随行」的。那就是git。(当然，这里也有个例，假设大家名目还逗留在svn阶段，就算我刚才的话唐突了)。
无论大家往常是青睐在命令行中手搓git命令，还是应用git可视化工具(SourceTree)启动代码治理。究竟都逃不过，add/commit/merge/push等命令的摆布。所以，当天我们来聊聊，在启动这些命令的时刻，在最底层究竟出现了啥。
还有一点，也算是一个认知优化吧。须要和大家唠叨一下，以后遇到比拟辣手的疑问，可以往这方面来聚拢
一切软件的底层成功都是「操作和治理数据」。
无论是我们往罕用到的桌面程序，亦或是在命令行中启动敲敲打打处置一些特定的操作，还有就是我们相熟的编程开发中，无论是前端的开发环节中，经常使用原生也好，各种框架也罢，最后的根结都是数据的列举和排布;还是后端就更显著了，有SQL的操作，那就更是再「愚弄」数据。之所以我们看到的现象有些不同，无非就是数据的体现方式和处置方式的不同。可以说，在编程界，--「万物皆数据」。
这里繁难举一个例子，日历大家都见过哇。
假设，给我们一个需求，要让我们成功一个飞书日历或许日历的开发义务，我们是不是一时觉失掉无法下手。
那我们往「万物皆数据」这个定论上靠，那是不是每一个「日程」（无论是繁难日程还是重复日程），它们实质上就是在每个小格子上展现。无非就是有的日程在单个格子上，有的日程是跨格子。而针对这种状况，是不是就是在以后视图中，我们须要保养一个数组，而这个数组中的项就是每个格子的示例。(针对月视图/周视图/日视图的数据，其实都是一套，只不过在框架外部为我们提供了各自的展现逻辑)
这是一个开源的日历库(FullCalendar)。
图片
而上方的events就是我们在日历上显示的日程信息。
图片
好了，天不早了，干点正事哇。
我们能所学到的常识点
1.前置常识点
「前置常识点」，只是做一个概念的引见，不会做深度解释。由于，这些概念在上方文章中会有出现，为了让行文愈加的顺畅，所以将本该在文内的概念解监禁到前面来。「假设大家对这些概念相熟，可以间接疏忽」同时，由于阅读我文章的个体有很多，所以有些常识点或许「我视之若珍宝，尔视只如草芥，弃之如敝履」。以下常识点，请「酌情经常使用」。
什么是git
Git是一种用于源代码治理的工具。它是一个收费且开源的版本控制系统，用于高效地处置从小型到十分大型的名目。Git用于跟踪源代码的更改，使多个开发人员能够独特在非线性开发中协作。Git是由LinusTorvalds于2005年为内核的开发而创立的。
集中式治理
在经常使用Git之前在保养代码之前，团队协作的形式如下：
图片
它的典型代表为SVN
散布式治理
图片
无须置疑，git是这方面的王者。
git基础概念
图片
gitinit--bareVSgitinit
gitinit--bare和gitinit是两种不同的Git初始化命令，它们用于创立不同类型的Git仓库。
上方是它们之间的关键区别：
普通状况下，假设我们须要创立一个新的Git仓库用于开发和保养代码，我们应该经常使用gitinit。假设我们须要创立一个中央版本库用于团队协作和共享代码，我们可以思考经常使用gitinit--bare。
钩子（Hooks）是一种通用概念，理论用于「在特定事情出现时触发自定义代码」。只管不是编程言语自身的一局部，但编程言语和开发工具理论提供一些机制来支持编写和经常使用钩子。
上方我们繁难引见几种大家比拟经常出现的应用Hook概念的技术。
|
称号 |
形容 |
示例语法 |
|
Git准许在代码仓库的特定事情上运转自定义脚本。事情包括提交、推送、兼并等。 |
经常使用Bash脚本编写，如
|
|
|
ScriptHooks |
JavaScript用于前端和后端开发，事情处置程序在特定事情出现时口头自定义JavaScript代码。 |
前端中，事情处置程序如事情监听器。后端中，经常使用EventEmitter模块。 |
|
ReactLifecycleHooks |
React用于构建用户界面，包括生命周期方法，准许在组件的不同生命周期阶段运转自定义代码。 |
生命周期方法如
当然，还有甚嚣尘上的针对函数组件的 |
|
GitHub提供Webhooks，是HTTP回调，用于在存储库的特定事情上触发自定义操作。 |
开发者编写Webhook处置程序照应事情，性能WebhookURL。 |
|
|
JenkinsPipelineHooks |
Jenkins是一个继续集成工具，准许创立自定义流水线脚本。经常使用钩子定义流水线的阶段和操作。 |
钩子嵌入到Jenkinsfile中以定义流水线。 |
GitHook是一种十分弱小的Git自定义「脚本系统」，它准许我们在Git版本控制环节的不同阶段口头自定义操作。这些操作可以是智能化测试、代码格局化、验证提交信息格局、预防性失误审核等等。Githooks是一种弱小的自定义工具，可以提高代码品质和协作效率。
「pre-commit」：在口头实践提交之前运转，用于口头「预提交审核」。
「pre-push」：在口头实践推送之前运转，用于「验证推送到远程仓库的内容」。
「pre-receive」：在接纳端口头，理论用于「验证推送到远程仓库的提交」。
「post-receive」：在接纳端口头，理论用于「通知或智能化部署」。
gitdiff命令后理论须要跟两个参数，参数1是要比拟的旧代码，参数2是要比拟的新代码。假设只写一个参数，示意自动跟workspace中的代码作比拟。
HEAD指向的是localrepository中的代码最新提交版本
git别名
在Git中，别名（GitAliases）是一种机制，准许我们为罕用的Git命令或命令序列创立冗长的自定义命令。别名使我们可以用更短、更易记的称号来口头罕用的Git操作，提高上班效率。
「1.创立别名：」我们可以经常使用gitconfig命令来创立Git别名。
gitconfig--globalalias.<alias-name><git-command-or-sequence><alias-name>：自定义别名的称号，我们可以选用任何青睐的称号。「2.例子：」以下是一些Git别名的例子：
gitconfig--globalalias.cocheckout#创立'co'别名来替代'checkout'gitconfig--globalalias.brbranch#创立'br'别名来替代'branch'gitconfig--globalalias.cicommit#创立'ci'别名来替代'commit'gitconfig--globalalias.ststatus#创立'st'别名来替代'status'gitconfig--globalalias.unstage'resetHEAD--'#创立'unstage'别名来敞开暂存「3.经常使用别名：」创立别名后，我们可以在命令行中经常使用它们。例如，经常使用上方的例子，我们可以这样口头命令：
gitcomy-branch#同等于'gitcheckoutmy-branch'gitbr-a#同等于'gitbranch-a'gitci-m"Message"#同等于'gitcommit-m"Message"'gitst#同等于'gitstatus'gitunstagefile.txt#同等于'gitresetHEAD--file.txt'从基本层面上说，Git只是一堆「经过文件名相互关联的文本文件」。
为了展示繁难，我们在本地的适合的文件夹中新建了一个dot_git的名目。
mkdirdot_git与此同时经过gitinit来初始化名目。
图片
如今让我们来看看.git文件夹中有什么内容。
我们经常使用erd来检查文件结构。
erd-yinverted.git文档结构如下
图片
看起来它创立了一堆文件和文件夹。让我们挑几个关键的来解释一下：
依据我们设置的自动分支是什么（gitconfig--globalinit.defaultBranch<分支称号>），它将是refs/heads/master(自动)，refs/heads/mn，或许我们设置的其余分支称号。
图片
「它指向了refs/heads文件夹」，并指向一个叫做master的文件，这个文件在我们启动第一次性提交之前是不存在的。
这个master文件「只会在我们启动第一次性提交后出现」。
3.新增一个文件
如今，我们曾经了解了.git目录中初始文件的状况，让我们口头第一个将内容减少到.git目录的操作。我们将创立一个文件并将其减少到暂存区（但还没有提交）。
echo'hello,789'>filegitaddfile我们继续经常使用erd-yinverted.git来检查文件变动。
图片
gitaddfile这会惹起两个关键的更改。
窥探objects中信息
我们经常使用file来检查一下内容是何方神圣。
file.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa:zlibcompressed>zlib-flate-uncompress<.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aablob10hello,789结果显示它蕴含了文件名为file的文件的类型、大小和数据。
也就是说，/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa示意它是一个大小为10的blob，内容是hello,789的数据。（只不过是被zlib处置了）
上方提到的/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa这是Git对象的一局部，用于存储文件内容。
留意，此时我们用到了zlib库，我们可以经过brewinstallzlib下载该库。(我是环境，其余环境大家自行寻觅处置方案)
文件名的由来
文件名来自内容的SHA-1hash值。
假设我们将zlib紧缩的数据经过sha1sum命令处置，我们会失掉文件名。
$zlib-flate-uncompress<.git/objects/c3/dc8e6cf3e1117a8d9731ddde9916da644296aa|sha1sumc3dc8e6cf3e1117a8d9731ddde9916da644296aaGit经常使用内容的SHA-1散列值，取「前两个字符」（在这种状况下是c3），创立一个文件夹，然后将残余局部用作文件名。Git从前两个字符创立文件夹，以确保我们不会在单个objects文件夹下有太多文件。
在Mac环境下，我们须要经过brewinstallmd5sha1sum
gitcat-file
由于objects的内容在Git中比拟关键，Git还特地提供了一个名为gitcat-file的命令，用于检查git对象的内容。经常使用gitcat-file命令
gitcat-file-tc3dc8e6cf3e1117a8d9731ddde9916da644296aablobgitcat-file-sc3dc8e6cf3e1117a8d9731ddde9916da644296aa10gitcat-file-pc3dc8e6cf3e1117a8d9731ddde9916da644296aahello,7894.gitcommit
既然，曾经将内容经过gitadd减少到Index（暂存区），接上去我们就须要将内容commit到localrepository：(本地仓库)
前面讲过，上方的ci同等于commit。
gitci-m'初次提交'继续经常使用erd-yinverted.git来检查目录结构
图片
嚯，一下多了很多文件。让我们来解读一下。
首先是一个新文件COMMIT_EDITMSG，它蕴含了（最新的）提交信息。
假设我们运转gitci命令而没有经常使用-m标记，那么Git失掉提交信息的方式是关上一个文本编辑器，经常使用COMMIT_EDITMSG文件来让用户编辑提交信息。一旦用户降级了信息并分开编辑器，Git就会经常使用该文件的内容作为提交信息。
它还减少了一个全新的logs文件夹。这是Git用来「记载仓库中一切提交更改的一种方式」。我们将能够「在这里看到一切refs和HEAD的提交更改」。
在refs/heads目录，其中新增了一个名为master的文件。这是对主分支（master）的援用。
经常使用cat检查关于的内容信息。
cat.git/refs/heads/masterfe010b33df5078cdbd96f2397aad60ec5f42a967看起来它指向了其中一个新对象。我们用内置命令cat-file检查内容。
$gitcat-file-tfe010b33df5078cdbd96f2397aad60ec5f42a967commit$gitcat-file-pfe010b33df5078cdbd96f2397aad60ec5f42a967tree658524b859ae78d902597253a3b68b4da3b70466authorxxx<xxx@simple>1697178492+0800committerxxx<xxx@xxx>1697178492+0800初次提交我们也可以经常使用以下命令检查该援用的类型：gitcat-file-trefs/heads/master
看起来这是一种新的对象类型，仿佛是一个「提交对象」（commitobject）。提交对象的内容通知我们，它蕴含一个哈希为658524b859ae78d902597253a3b68b4da3b70466的「树对象」（treeobject），这看起来就像我们在提交时减少的另一个对象。提交对象还蕴含了作者和提交者的信息。最后，它还显示了这个提交的提交信息是什么。
我们继续来看看树对象蕴含了什么内容。
gitcat-file-t658524b859ae78d902597253a3b68b4da3b70466treegitcat-file-p658524b859ae78d902597253a3b68b4da3b70466100644blobc3dc8e6cf3e1117a8d9731ddde9916da644296aafile我们会发现该文件指向了在我们口头gitaddfile时减少的原始对象(c3dc8e6cf3e1117a8d9731ddde9916da644296aa)。
图片
树对象外部经常使用更多的树对象来示意文件夹，这些树对象与提交对象相连，用于示意目录结构。
5.新增修正
让我们对文件启动更改并检查它是如何上班的。
echo'git,hello,789'>filegitci-am"修正文件内容"还是应用erd检查文档目录
图片
一个蕴含文件新内容的blob对象
一个是一个树对象
最后一个是一个提交对象
让我们再次从HEAD或refs/heads/master开局跟踪它们。
gitcat-file-prefs/heads/mastertree02185c57f2040abcaa0c67dfd7026464d916da2bparentfe010b33df5078cdbd96f2397aad60ec5f42a967author789<789@xx.net>1697179597+0800committer789<789@xxx.net>1697179597+0800修正文件内容gitcat-file-p02185c57f2040abcaa0c67dfd7026464d916da2b100644blob1f9224976e282aa9e32398a5bca0cec08041f1dcfilegitcat-file-p1f9224976e282aa9e32398a5bca0cec08041f1dcgit,hello,789提交对象如今有一个额外的属性，名为parent，它链接到「前一个提交」，由于这个提交是树立在前一个提交之上的。
这是Git中的提交历史的关键概念，
每个提交都有一个或多个父提交，构成一个提交链。
6.创立分支
是时刻创立一个分支了。让我们经常使用gitbrfix-text命令创立一个名为fix-text的分支。
前面讲过，上方的br同等于branch。
图片
这将在refs/heads文件夹下创立一个新文件，文件名为分支称号，文件内容为最新提交的ID。
我们首先用gitlog检查提交记载
图片
发现最新的提交记载为efa223e697c6452a393963887f9926ea0662c923
cat.git/refs/heads/fix-textefa223e697c6452a393963887f9926ea0662c923在Git中，分支是十分轻量级的。标签（Tags）的行为也相似，只不过它们是创立在refs/tags下的。
还会在logs目录下减少一个文件，用于存储与主分支相似的提交历史数据。这有助于跟踪各个分支的提交历史。Git的分支和标签是十分有用的版本控制工具，可以协助我们治理名目标不同形态和版本。
7.分支切换
在Git中，检出（checkout）操作是失掉「提交」的树对象，并将workingtree中的文件降级为与树对象记载的形态相婚配。
图片
在这种状况下，由于我们从master切换到fix-text，而这两个分支「都指向相反的提交和底层树对象」，Git在workingtree中没有任何事情要处置。
前面讲过，上方的co同等于checkout。
gitcofix-text在.git目录外口头co操作时，惟一的变动是.git/HEAD文件如今将指向fix-text。
cat.git/HEADref:refs/heads/fix-text另外，让我启动一次性提交。
echo'hello,git'>filegitci-am"改换文本内容"这将在fix-text分支上创立一个新的commit，将文件file中的内容更改为hello,git。
8.分支兼并
兼并（merging）有关键三种方式。
首先，让我们看看在兼并之前图形是什么样子。(先将分支切换回master(gitcomaster))
gitlog--graph--oneline--all*4359ab4(fix-text)改换文本内容*efa223e(HEAD->master)修正文件内容*fe010b3初次提交口头兼并操作
gitmergefix-text降级efa223e..4359ab4Fast-forwardfile|2+-1filechanged,1insertion(+),1deletion(-)上方的操作，将一个master分支的援用（指向的哈希值）降级为fix-text分支的援用指向的哈希值。
gitlog--graph--oneline--all*4359ab4(HEAD->master,fix-text)改换文本内容*efa223e修正文件内容*fe010b3初次提交9.远程提交
为了展示这一点，首先让我创立另一个Git仓库，它可以作为这个仓库的远程仓库。
新建一个「裸」仓库
$mkdirfake_git_remote$cdfake_git_remote&&gitinit--bare切换到我们dot_git名目中，为仓库设置remote
gitremoteaddorigin../fake_git_remote顺便说一下，减少一个新的远程仓库是一项性能更改，我们可以在.git/config文件中检查这个更改。我会让我们自己去检查这个更改是什么。
图片
如今让我们启动推送操作。
gitpushoriginmaster让我们看看我们的本地仓库中出现了什么变动。
图片
它减少了一个新的refs/remotes，用于存储无关不同远程仓库中的一切可用内容的信息。
然而发送到另一个Git仓库的是什么呢？实践上，
发送的内容就是.git/objects目录中的一切对象，以及我们显式推送的refs下的一切分支和标签。
这就是另一个Git仓库须要失掉我们的完整Git历史记载所需的一切内容。
图片
Git工作原理
按照官方文档的描述，Git是这样定义的 目录是Git的核心，每一个变动都会存储在文件夹中，Git的相关命令本质上也是读取文件夹下的内容 目录下有几个重要的文件/文件夹 提交和文件是Git中的主要组成，也叫git对象，Git中的许多命令都和git对象有关 git对象分为下面3类 git对象存储在目录下的objects文件夹中，Git会将git对象压缩成二进制文件，git对象的文件名即sha-1算法得到的hash值，按照2/38的形式保存（前两位是文件夹的名称，剩下38位是文件名，这样做可以防止文件夹的内容过多，提高查找效率） 对于commit对象，hash值也被称为commitid 可以使用以下命令查看git对象中的内容 git cat-file -p <hash> 通过查看三种git对象的内容，不难发现如下的组织关系 其实可以吧hash看成每个对象的指针，Git通过指针将众多git对象串联起来，来实现对项目的版本控制 用户通过Git命令读写文件夹，达到获取信息或变更版本的目的 Git一开始被设计成供VCS使用的工具集合而不是一整套用户有好的VCS，它还包含了许多的底层命令，一般被称为plumbing命令（底层命令），而用户日常使用Git命令被称为porcelain命令（高层命令），porcelain命令实际是是对plumbing命令的封装 一次完整的提交过程会包含如下过程 使用porcelain命令的话是非常简单的 如果使用plumbing命令就会复杂很多，但是可以更好地理解其背后的工作原理 通过前文的内容不难发现，每次生成的commit对象会包含上一个commit对象的hash，即当前的commit包含上一个commit的指针，许多个commit对象串联起来就形成了分支 所以，Git的分支本质上是指向commit对象的可变指针 而HEAD代表当前commit的指向，/refs/heads/<branchname>文件的内容就是该commit对象的hash
git的文件系统与底层原理
由于工作中使用git作为版本管理，之前对git的了解不多，特别是底层方面的原理方面的知识。为了能更好的使用git，有必要学习并梳理下相关知识。
步入正题：
执行git init 初始化后，会在文件夹下会创建多个目录，每个文件夹功能划分的很清晰。
Git 是一套内容寻址文件系统.通过键值对的方式存储和查找。
下面操作一遍，直观的看到整个过程，以便理解。
参考：
参考：
可以见到文件名称为数字和字母组成的字符串。这个是根据文件内容和头信息（Header），通过SHA-1算法计算得出的40位十六进制校验和。
SHA-1是一种加密哈希函数（cryptographic hash function）。SHA-1将文件中的内容通过其hash算法生成一个160bit的报文摘要，即40个十六进制数字（每个十六进制数字占4位）。它几乎可以保证，如果两个文件的SHA-1值是相同的，那么它们确是完全相同的内容（类似于生活中的指纹识别）；SHA-1主要有两种用途，一个是加密，一个是数据完整性校验。Linux kernel开创者和Git的开发者——Linus说，Git使用了SHA-1并非是为了安全性，而是为了数据的完整性。理论上SHA-1会在2^51攻击下实现哈希碰撞，所以也不是完全的安全。
参考：
模拟bolb对象存储流程
以上，说明了git的数据存储的基本方式。主要步骤：
下面是创建文件，修改文件，恢复文件的相关过程。
git会记录每个版本的修改，根据校验和可恢复到相应的版本。
小结： 这个过程中包括文件创建、文件修改、文件恢复，跟我们平时工作中使用的高级命令功能很相似。git会把整个过程转化为底层操作，同时对用户透明。
相关引用参考：
免责声明：本文转载或采集自网络，版权归原作者所有。本网站刊发此文旨在传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题，请联系本网，我们将在第一时间删除。同时，本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证，请读者仅作参考，并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失，本网站不承担任何责任。
