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

【腾讯云】买域名送云解析+SSL证书+建站!>>>   

本文已被《Git版本控制 —— 原理简述》替换:https://my.oschina.net/u/3452433/blog/1796162

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

 

前言

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

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

 

分布式管理

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

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

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

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

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

 

代码提交

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

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

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会向前查找每次提交直至找到共同的起点。然后会比较两个分支修改了那些文件,最后将修改的文件进行合并。这里需要注意如果修改的是,不同文件则那个分支做出了修改就用那个分支的版本,如果修改了相同的文件我们就要手动处理冲突(之后再说)。

 

变基

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

变基操作时先找到两个分支共同的起点,然后把当前分支在这个起点之后所有的提交都做成补丁。最后将这些补丁在目标分支上重新执行一遍。

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

 

冲突处理

当不同分支修改了同一个文件时,就会产生冲突。很少的情况下冲突是可以自动解决的,比如都在文件结尾处新增了一部分内容。大部分的情况需要我们手动处理冲突。

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

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

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

 

远程分支

为了能够进行团队合作,开发人员会通过远程分支管理和交换代码。远程跟踪分支是远程分支状态的引用。 它们是你不能移动的本地引用,当你做任何网络通信操作时,它们会自动移动。 远程跟踪分支像是你上次连接到远程仓库时,那些分支所处状态的书签。它们以 (remote)/(branch) 形式命名。 例如,如果你想要看你最后一次与远程仓库 origin 通信时master 分支的状态,你可以查看 origin/master 分支。 

 

跟踪分支

从一个远程跟踪分支检出一个本地分支会自动创建一个叫做 “跟踪分支”(有时候也叫做 “上游分支”)。 跟踪分支是与远程分支有直接关系的本地分支。 如果在一个跟踪分支上输入 git pull,Git 能自动地识别去哪个服务器上抓取、合并到哪个分支。

当克隆一个仓库时,它通常会自动地创建一个跟踪 origin/master 的 master 分支。 然而,如果你愿意的话可以设置其他的跟踪分支 - 其他远程仓库上的跟踪分支,或者不跟踪 master 分支。

 

标签

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

 

 

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