Git版本控制 —— 原理概述
Git版本控制 —— 原理概述
啊哼哼 发表于3个月前
Git版本控制 —— 原理概述
  • 发表于 3个月前
  • 阅读 26
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 新注册用户 域名抢购1元起>>>   

Git是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。

 

前言

关于git是什么,git的工作原理,网上的资料已经非常多了。本人菜鸟固然不会比各路大神写的好。

所以本篇博文只按照我自己最肤浅的理解,使用白话进行阐述。主要目的以后自己能看懂,水平不高的读者也能看懂。

 

分布式管理

所谓分布式管理就是所有参与git项目的人,在自己的本地都会有一套完整的版本库。而对于传统的svn类型的集中式版本管理而言完整的版本库只有一套在服务器上,参与的人只不过拷贝了某一分支的代码而已。

分布式管理目前被某些“信徒”鼓吹的好的不得了,但我看来也是要具体情况具体分析的。

1、项目组人员水平参差不齐,不是所有人都能够摆弄清楚分支管理的。svn时期我自己就能把版本库分支维护的利利索索。而这种本地任意管理分支的情况让一些水平较差的程序员管理的非常混乱,甚至导致丢失未提交的代码。

2、团队协作比较密切的时候提交代码是非常频繁的,往往我刚写完一个实体,同事马上就要求我提交。git的提交显然是比较繁琐的。

总结来说git对于开源项目是非常合适的。代码贡献者能够轻松地获取整个版本库,然后在开发完整块代码后申请合并。而在一个人员能力不足,团队代码提交频繁的项目中也不一定是最好的选择。

 

代码提交

git的代码提交要比svn来的繁琐,而且理念与svn也是不一样的。

先说一下git的本地代码提交,由于git在本地会有一个完整的版本库,所以本地其实就相当于拥有了一个原来的svn系统。所以在本地就可以完成所有的代码提交工作,至于核心仓库问题一会儿再说。

git会将代码放在“工作区”“暂存区”“分支”三个部分。代码提交工作其实就是把代码从“工作区”转移到“暂存区”再转移到“分支”的过程。

 

其实从git设计角度来说根本不存在什么核心库的概念。只不过一般情况下为了便于管理我们会指定一个库作为“核心仓库”来使用,程序员把代码上传到核心仓库的过程其实是,本地分支(master)与远程分支(origin )的代码合并。所以对于git来说向远程仓库上传代码并不是“提交“而是"合并"。

 

分支

git的分支使用上基本与svn一致,我们可以从一个分支(最开始是主分支master)创建出新的分支。

但是从原理上git的分支切换要比svn快速方便的多。

先说一下svn的分支使用。我们首先需要在svn仓库中创建一个分支(这个步骤是非常快的),然后我们需要把新建的分支检出到本地(这步就非常慢了)。由于检出需要使用互联网将分支下载下来,会非常的耽误事。曾经做过一个银行项目,公司要求无论改什么都要创建分支,项目挺大检出一次基本10分钟左右。

现在再来说一下git。在本地仓库中创建一个分支,然后直接切换到分支进行开发,这两个步骤都是秒完成。

下面介绍一下git分支原理来说明一下为什么这么快。

分支是指针

git的提交行为就是将当前文件保存,然后在创建一个最新的文件,就完成了一次提交。而分支其实就是一个指向某次提交的指针,提交一次,指针向后移动一次。

如下图所示,第一次提交的三个文件(文件1、文件2、文件3),分支指针指向第一次提交。第二次提交了一个文件(文件2),在提交中创建了新的文件二,指针移动指向第二次提交,文件1和文件3由于没有新的提交还是使用第一次提交的。以此类推第三次提交了两个文件(文件1、文件2),分支指针指向第三次提交。

 

分支之间的关系

分支就是不同的指针,分别指向了不同的提交。

如下图所示,一开始只有master分支。在提交2的时候创建了new分支。然后就按照各自的提交路线走下去了。

分支的切换

分支切换其实就是一个区分谁是当前分支的问题。这里又用到了一个指针HEAD,HEAD指向了当前分支,切换分支实际上就是改变了HEAD的指向。

 

分支的合并

合并时如果文件没有冲突是比较好解决的直取最新的就行了,难点就在于有冲突的文件合并。

有冲突的文件合并主要分为两种方式即 手动合并变基

手动合并

手动合并时git会提示那些文件有冲突,并比较出冲突的代码进行提示。我们手动决定保留哪些代码后再进行一次提交从而解决冲突。

如下图文件1要从new分支合并到master分支,出现冲突手动解决并提交。

 

变基

当年被这个词吓得不轻。太高大上了“变鸡”听着就牛逼。其实说起来也没啥,挺简单一个概念。

变基就是在文件产生冲突时,找到两个分支共同的祖先,然后把当前分支在这个祖先之后所有的提交都做成补丁。最后将这些补丁在目标分支上重新执行一遍。

用图示说明一下,现在我们要将new分支采用变基的方式合并到master分支。他们共同的祖先是提交2,new分支合并时发现冲突后,将提交2之后的提交,也就是提交4和提交5生成补丁。最后将这两个补丁在master分支进行执行。

 

最后总结一下,看没看见git所有的分支操作都是创建文件和移动指针,这也就是快的原因。

 

标签

标签就是一个指针,指向了某一次提交,并且标签是不能移动的。

 

 

共有 人打赏支持
粉丝 3
博文 37
码字总数 39375
×
啊哼哼
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: