一文彻底搞懂Git分支原理【云驻计划】

举报
龙哥手记 发表于 2022/03/01 10:40:03 2022/03/01
【摘要】 系列篇请多多关注

title: Git分支-分支原理
date: 2020-11-18 17:43:57
permalink: /pages/4bef1a/
categories:

  • 《Git》学习笔记
    tags:

Git分支-分支原理

Git 处理分支的方式可谓是难以置信的轻量,创建新分支这一操作几乎能在瞬间完成,并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同,Git 鼓励在工作流程中频繁地使用分支与合并,哪怕一天之内进行许多次。

首次提交

在进行提交操作时,Git 会保存一个提交对象(commit object)。

假设现在有一个工作目录,里面包含了三个将要被暂存和提交的文件。 暂存操作会为每一个文件计算校验和(使用 SHA-1 哈希算法),然后会把当前版本的文件快照保存到 Git 仓库中 (Git 使用 blob 对象来保存它们),最终将校验和加入到暂存区域等待提交:

$ git add README test.rb LICENSE
$ git commit -m 'The initial commit of my project'

当使用 git commit 进行提交操作时,Git 会先计算每一个子目录(本例中只有项目根目录)的校验和, 然后在 Git 仓库中这些校验和保存为树对象。随后,Git 便会创建一个提交对象, 它除了包含上面提到的那些信息外,还包含指向这个树对象(项目根目录)的指针。 如此一来,Git 就可以在需要的时候重现此次保存的快照。

现在,Git 仓库中有五个对象:三个 blob 对象(保存着文件快照)、一个 树对象 (记录着目录结构和 blob 对象索引)以及一个 提交对象(包含着指向前述树对象的指针和所有提交信息)。

图1. 首次提交对象及其树结构 ▲

小结:

  1. git add 加入暂存操作,会为每个文件创建计算校验和,以及每个文件对应的文件快照(blob对象)。

  2. git commit 提交操作,计算子目录或跟目录的校验和 保存为树对象。随后,创建一个提交对象,包含着指向树对象的指针和所有提交信息。

再次提交

做些修改后再次提交,那么这次产生的提交对象会包含一个指向上次提交对象(父对象)的指针。

图2. 提交对象及其父对象 ▲

Git 的分支

Git 的分支,其实本质上仅仅是指向提交对象的可变指针。 Git 的默认分支名字是 master。 在多次提交操作之后,你其实已经有一个指向最后那个提交对象的 master 分支。 master 分支指针会在每次提交时自动向前移动

Git 的 master 分支并不是一个特殊分支。 它就跟其它分支完全没有区别。

图3. 分支及其提交历史 ▲

创建分支

Git 是怎么创建新分支的呢? 很简单,它只是为你创建了一个可以移动的新的指针。 比如,创建一个 testing 分支, 你需要使用 git branch 命令:

$ git branch testing

这会在当前所在的提交对象上创建一个指针。

图4. 两个指向相同提交历史的分支 ▲

当前分支的指针

Git 是怎么知道当前在哪一个分支上呢? 很简单,它有一个名为 HEAD 的特殊指针指向当前所在的本地分支(译注:HEAD 想象为当前分支的别名)。 在本例中,你仍然在 master 分支上。 因为 git branch 命令仅仅 创建 一个新分支,并不会自动切换到新分支中去。

图5. HEAD 指向当前所在的分支 ▲

查看当前所在分支

你可以简单地使用 git log 命令查看各个分支当前所指的对象。 提供这一功能的参数是 --decorate

$ git log --oneline --decorate
f30ab (HEAD -> master, testing) add feature # f30ab提交对象 (HEAD当前所在分支 -> master分支,testing 分支)
34ac2 Fixed bug # 34ac2 提交对象
98ca9 The initial commit of my project # 98ca9 提交对象

正如你所见,当前 mastertesting 分支均指向校验和以 f30ab 开头的提交对象。

分支切换

$ git checkout testing  # git checkout <分支名>

这样 HEAD 就指向 testing 分支了。

图6. HEAD 指向当前所在的分支 ▲

那么,这样的实现方式会给我们带来什么好处呢? 现在不妨再提交一次:

$ vim test.rb
$ git commit -a -m 'made a change'

图7. HEAD 分支随着提交操作自动向前移动 ▲

如图所示,你的 testing 分支向前移动了,但是 master 分支却没有,它仍然指向运行 git checkout 时所指的对象。 这就有意思了,现在我们切换回 master 分支看看:

$ git checkout master

图8. 检出时 HEAD 随之移动 ▲

这条命令做了两件事一是使 HEAD 指回 master 分支,二是将工作目录恢复成 master 分支所指向的快照内容。 也就是说,你现在做修改的话,项目将始于一个较旧的版本。 本质上来讲,这就是忽略 testing 分支所做的修改,以便于向另一个方向进行开发。

我们不妨再稍微做些修改并提交:

$ vim test.rb
$ git commit -a -m 'made other changes'

现在,这个项目的提交历史已经产生了分叉(参见 项目分叉历史)。 因为刚才你创建了一个新分支,并切换过去进行了一些工作,随后又切换回 master 分支进行了另外一些工作。 上述两次改动针对的是不同分支:你可以在不同分支间不断地来回切换和工作,并在时机成熟时将它们合并起来。 而所有这些工作,你需要的命令只有 branchcheckoutcommit

图9. 项目分叉历史 ▲

你可以简单地使用 git log 命令查看分叉历史。 运行 git log --oneline --decorate --graph --all ,它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) made other changes
| * 87ab2 (testing) made a change
|/
* f30ab add feature
* 34ac2 fixed bug
* 98ca9 initial commit of my project

由于 Git 的分支实质上仅是包含所指对象校验和(长度为 40 的 SHA-1 值字符串)的文件,所以它的创建和销毁都异常高效。 创建一个新分支就相当于往一个文件中写入 41 个字节(40 个字符和 1 个换行符),如此的简单能不快吗?

这与过去大多数版本控制系统形成了鲜明的对比,它们在创建分支时,将所有的项目文件都复制一遍,并保存到一个特定的目录。 完成这样繁琐的过程通常需要好几秒钟,有时甚至需要好几分钟。所需时间的长短,完全取决于项目的规模。 而在 Git 中,任何规模的项目都能在瞬间创建新分支。 同时,由于每次提交都会记录父对象,所以寻找恰当的合并基础(译注:即共同祖先)也是同样的简单和高效。 这些高效的特性使得 Git 鼓励开发人员频繁地创建和使用分支。

创建分支同时切换

通常我们会在创建一个新分支后立即切换过去,可以使用如下命令:

git checkout -b <newbranchname> 
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。