[Git系列] Git 基本概念

版本控制系统

版本控制系统是一种帮助软件开发者实现团队合作和历史版本维护的软件,一个版本控制系统应具备以下列出的这几个基本功能:

  • 允许开发者并发工作;
  • 不允许一个开发者覆写另一个开发者的修改;
  • 保存所有版本历史。

版本控制系统可以分为如下两类:

  • 集中式版本控制系统;
  • 去中心式(分布式)版本控制系统。

Git 是一种分布式版本控制系统。在这一章里,我们将着重介绍分布式版本控制系统,特别是重点介绍 Git。

分布式版本控制系统

集中式版本控制系统是用一个中央服务器存储所有文档并在此中央服务器上实现团队合作,此种系统的主要弊端在于中央服务器可能发生的单点故障:如果中央服务器不幸宕机一小时,那么这一小时内就完全不能合作开发了。此种弊端能导致的最糟糕的情况是,如果中央服务器在成功备份之前完全崩溃,那么中央服务器中所存储的此项目的所有历史版本都将丢失。这时,就该考虑一下分布式的版本控制系统了。

分布式版本控制系统中的客户端不仅可以查验项目目录的最新快照,而且可以镜像整个仓库。如果服务器宕掉了,任何一个客户端存储的仓库镜像都能作为备份用来恢复。每一次查验都会形成一个仓库的完整备份。Git 并不依赖于中央服务器,这样开发者就能在离线情况下也进行各种操作。开发者能够在离线情况下进行提交、创建分支、查看日志等操作,只有要公布自己的变更或者获取最新的变更版本时才需要连接网络。

Git 的优势

免费且开源

Git 是遵循 GPL 开源许可的发行软件,在整个互联网上都可以免费获取。你可以用 Git 来管理财产相关工程而不用花一分钱,而且因为它是开源的,你还可以下载源码按自己的需求对它进行改造。

快捷轻便

因为绝大多数操作都可以在本地完成,这让速度得到了很大的提升。Git 并不依赖中央服务器,这就是为什么没有必要每个操作都得和远端服务器交互的原因。Git 的核心部分是用 C 语言写成的,这避免了使用更高级语言造成的运行时间上的浪费。尽管 Git 镜像了整个仓库,客户端的数据量仍然很小,这很好地说明了 Git 在客户端压缩存储数据的效率有多高。

默认的备份

当存在很多份镜像复制时,数据丢失的可能性就大大减小了。任何客户端上的数据都是仓库的镜像,这些数据在系统崩溃或硬盘损毁时都可以用来恢复。

安全

Git 使用一种叫做安全散列算法(SHA1)的加密方法去命名并识别数据库中的对象。每个文件和每次提交都会加上校验码供验证,每次取出数据也都得使用校验码校验。这意味着在不了解 Git 的情况下,开发者不可能成功进行修改文件数据、提交信息或者其他会改变 Git 项目数据库的操作。

硬件资源要求不高

在使用集中式版本控制系统时,需要的中央服务器必须足够强大以支撑团队所有成员的请求。对于小型开发团队来说,这个问题不难解决,但是如果团队规模不断增大,服务器的硬件限制就会成为瓶颈。在分布式版本控制系统中,开发者只有在推出(push)或拉取(pull)修改时才需要连接服务器,所有负担较重的工作都在客户端这边完成,所以服务器的硬件条件就可以从简规划。

更简单的分支管理

集中式版本控制系统使用一种简单的复制机能,如果我们在其中创建一个分支,那么该分支会将项目所有代码拷贝在新的分支中,此方法效率不高且颇费时间,而且在集中式版本控制系统中删除和合并分支都很复杂且耗时长。但是分支管理在 Git 中容易多了,在 Git 中创建、删除和合并分支均只会花费很少的时间。

分布式存储系统中的术语

本地库 (Local Repository)

所有版本控制系统工具都会提供个人工作空间,在其中对复制下来的工程项目进行操作,开发者在自己的个人工作空间中做出改动然后提交,这些改动也就成为了项目仓库的一部分。Git 更进一步为开发者们提供整个仓库的私人复制本,开发者们可以对这个仓库进行任何操作,比如增加文件、删除文件、移动文件、提交修改等。

工作目录、暂存区或索引(Working Directory and Staging Area or Index)

工作目录即文档被拉取或创建后所在的目录位置。在集中式系统中,开发者们通常做出修改然后将更改项直接提交给仓库。Git 不同,Git 不会追踪每次每个被修改的文档,不论何时你提交了一个操作,Git 都会搜寻暂存区现有的文档,不是所有被修改的文档而是只有暂存区现存的文档会被纳入考虑。

让我们来看看 Git 的基本工作流:

  • 第一步 —— 在工作目录下修改一个文档;
  • 第二部 —— 将此文档加入暂存区;
  • 第三步 —— 进行提交操作,此操作从暂存区将文档移入本地库中,完成推出(push)的操作后,此变动就永久保存在了 Git 仓库里了。

如果你修改了两个文件,sort.csearch.c,并且你想为这两次修改分别进行两次提交,这时,你可以先将一个文件添加进暂存区再提交,然后按这种方式处理下一个文件。操作示例如下,-m 后面的参数为本次提交的说明:

# First commit
[jerry@CentOS ~]$ git add sort.c

# adds file to the staging area
[jerry@CentOS ~]$ git commit –m “Added sort operation”

# Second commit
[jerry@CentOS ~]$ git add search.c

# adds file to the staging area
[jerry@CentOS ~]$ git commit –m “Added search operation”

二进制大型对象(Blobs)

Blob 是 Binary Large Object (二进制大型对象)的缩写,每个版本的文件都以 blob 类型呈现。blob 包含文件的所有数据,但唯独没有文件的元数据。这是一种二进制文件,在 Git 数据库中,它以“文件的安全散列哈希”闻名。在 Git 中,文件并不是按名字而是按内容来处理的。

树(Trees)

树是一种对象,代表一个目录。它包含 blob 类型的文件和其他子目录,一棵树即是一个存储指向 blob 的索引或者被称为树对象的安全散列哈希的二进制文件。

提交操作(Commits)

提交操作维持着仓库的当前状态,一个提交也会被安全散列哈希指名。你可以将提交操作对象看作链表的一个节点,每个提交操作对象都有一个指向父提交节点的指针。从给定的一个提交中,你能通过查找父指针去回溯查看提交的历史。如果一个提交有不止一个父提交,那么此提交是通过两个分支合并来创建的。

分支(Branches)

分支用于创建发开的另一线路。默认情况下,Git 有一个 master 分支,此分支如同另一种版本管理工具 Subversion 即 SVN 中的树干 trunk。通常来说,一个分支用于一个新功能的开发,一旦新功能开发完成,就将这个分支合并到 master 上,然后删除这个分支。每个分支都可由 HEAD 指示,HEAD 在不指定的情况下总是指向分支的最新一次提交状态。不论何时你完成一次提交操作,HEAD 都会以最新的提交操作来更新自己。

标签(Tags)

标签能给仓库中某个特定版本分配一个有意义的名字。标签和分支很相似,不同的地方在于标签是不变动的。这意味着,标签是一种没人去修改的分支。一旦为某个特定提交操作创造了一个标签,即使你再完成一次新的提交操作,它也不会更新。一般开发者会给产品的发行版本创建标签。

克隆(Clone)

克隆操作会给仓库创建一个实例。克隆不仅能检视当前工作的副本,而且能镜像整个仓库。用户能在本地仓库上完成各种操作,只有在仓库实例同步时才需要连接网络。

拉取(Pull)

拉取操作将远端仓库实例的变动拷贝到本地,此操作用于两个仓库实例的同步中。pull 操作与 SVN 中的 update 操作效果相同。

推出(Push)

推出操作将本地的仓库实例发生的变动拷贝到远端仓库中,此操作常用于将对本地做的改动永久存储到 Git 仓库中。push 操作与 SVN 中的 commit 操作效果相同。

HEAD

HEAD 是一个指针,它永远指向分支中的最新提交内容。不论何时你完成一次提交,HEAD 总会随着最近的一次提交而更新。分支的 heads 存储在 .git/refs/heads/ 目录下。

[jerry@CentOS ~]$ ls -1 .git/refs/heads/
master

[jerry@CentOS ~]$ cat .git/refs/heads/master
570837e7d58fa4bccd86cb575d884502188b0c49

修订(Revision)

修订即是源代码的改版,在 Git 中修订由提交体现,而这些提交操作则由安全散列算法认定识别。

URL

URL 表示 Git 仓库的位置,该项内容存储在 Git 的设定文件 .git\config 里。

[gituser@CentOS ~]$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = gituser@git.server.com:project.git
fetch = +refs/heads/*:refs/remotes/origin/*

我已经将Git系统文章整理成电子书,请点击以下链接免费获取:

链接:https://pan.baidu.com/s/1mM6jK9B0GuYUYtDD_2lKFA
提取码:1234


最后,最近很多小伙伴找我要Linux学习路线图,于是我根据自己的经验,利用业余时间熬夜肝了一个月,整理了一份电子书。无论你是面试还是自我提升,相信都会对你有帮助!

免费送给大家,只求大家金指给我点个赞!

电子书 | Linux开发学习路线图

也希望有小伙伴能加入我,把这份电子书做得更完美!

有收获?希望老铁们来个三连击,给更多的人看到这篇文章

推荐阅读:

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342

推荐阅读更多精彩内容