Git（12）-- Git 分支 - 分支简介

[超详细 Git 图文版小白教程（持续更新）](https://blog.csdn.net/m0_46278037/article/details/119801677)

几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。 在很多版本控制系统中，这是一个略微低效的过程——常常需要完全创建一个源代码目录的副本。对于大项目来说，这样的过程会耗费很多时间。

有人把 Git 的分支模型称为它的“必杀技特性”，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。 为何 Git 的分支模型如此出众呢？ Git 处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同，Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次。 理解和精通这一特性，你便会意识到 Git 是如此的强大而又独特，并且从此真正改变你的开发方式。

1、分支简介

为了真正理解 Git 处理分支的方式，我们需要回顾一下 Git 是如何保存数据的。

Git 保存的不是文件的变化或者差异，而是一系列不同时刻的 快照（snapshot） 。

在进行提交操作时，Git 会保存一个提交对象（commit object）。 知道了 Git 保存数据的方式，我们可以很自然的想到——该提交对象会包含一个指向暂存内容快照的指针。 但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。 首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象， 而由多个分支合并产生的提交对象有多个父对象，

为了更加形象地说明，我们假设现在有一个工作目录，里面包含了三个将要被暂存和提交的文件。 暂存操作会为每一个文件计算校验和（使用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 就可以在需要的时候重现此次保存的快照。

1.1、初始化并首次提交

新建testbranch文件夹，右键，点Git Bash Here

初始化为Git仓库：

git init
git status

新建README 、test.rb和 LICENSE三个文件，此时这三个文件内容都为空：

git status

添加到暂存区并提交：

git add README test.rb LICENSE
git status

git commit -m 'The initial commit of my project'

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

先放总结图：

首次提交对象及其树结构：

在git中，blob与文件名无关，只与文件内容有关，即文件内容相同，在git中是同一个blob。

用命令详细查看：

git log

git 的 cat-file 的命令用法：

git cat-file 的命令显示版本库对象的内容、类型、及大小信息。

-t
Instead of the content, show the object type identified by object.
显示对象的类型。

-s
Instead of the content, show the object size identified by object.
显示对象的大小。

-e
Suppress all output; instead exit with zero status if object exists and is a valid object.
如果对象存在且有效，命令结束状态返回值为0。

-p
Pretty-print the contents of object based on its type.
根据对象的类型，以优雅的方式显示对象的内容

git cat-file -p f79e0ab69485aad8a166921f6113831b95f30ad1

git cat-file -p 5686f60e688ae43df28beea0f49055e605cfc0ba

再次强调：
在git中，blob与文件名无关，只与文件内容有关，即文件内容相同，在git中是同一个blob。

以上是第一次提交。做些修改后再次提交，那么这次产生的提交对象会包含一个指向上次提交对象（父对象）的指针。

1.2、修改并第二次提交

修改三个文件后再提交：

git status
git add README test.rb LICENSE
git commit -m 'Two commit of my project'

git log

git cat-file -p 4c01aba72850b2fc4839aa75cba3c92adcb7df02

git cat-file -p 8da9abb302345ac3855ab05ec79c52ce95c58feb

git cat-file -p 7153628ea778a52e8acb0b78701df26a8b4f19e4
git cat-file -p d2fb9a2df3a1cfd26f5941bd3f19f54d1da2d09a
git cat-file -p 35ce91f3f87d134161a22067d485c52cd9deb612

第二次提交对象及其树结构：

1.3、修改并第三次提交

第三次修改并提交：

git status
git add README test.rb LICENSE

git status
git commit -m '3 commit'

git log

 git cat-file -p bce8f7b

git cat-file -p 455f296

git cat-file -p 11e6485
git cat-file -p 389ed9c
git cat-file -p 50c0fe6

提交对象及其父对象图：

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

Git 的 main 分支并不是一个特殊分支。 它就跟其它分支完全没有区别。 之所以几乎每一个仓库都有 main 分支，是因为git init 命令默认创建它，并且大多数人都懒得去改动它。

git log -p -1

git tag -a v1.0 -m "first version"
git tag

git log -p -1

分支及其提交历史图：

2、分支创建

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

git branch testing

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

两个指向相同提交历史的分支图：

那么，Git 又是怎么知道当前在哪一个分支上呢？ 也很简单，它有一个名为 HEAD 的特殊指针。 请注意它和许多其它版本控制系统（如 Subversion 或 CVS）里的 HEAD 概念完全不同。 在 Git 中，它是一个指针，指向当前所在的本地分支（译注：将 HEAD 想象为当前分支的别名）。 在本例中，你仍然在 main 分支上。 因为 git branch 命令仅仅 创建 一个新分支，并不会自动切换到新分支中去。

HEAD 指向当前所在的分支图：

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

git branch testing
git log --oneline --decorate

正如你所见，当前 main 和 testing 分支均指向校验和以bce8f7b开头的提交对象。

3、分支切换

要切换到一个已存在的分支，你需要使用 git checkout 命令。 我们现在切换到新创建的 testing 分支去：

git checkout testing

这样 HEAD 就指向 testing 分支了。

HEAD 指向当前所在的分支图：

git checkout testing
git log --oneline --decorate

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

git status
git commit -a -m 'made a change'
git log --oneline --decorate

如图所示，你的 testing 分支向前移动了，但是 main分支却没有，它仍然指向运行 git checkout 时所指的对象：

HEAD 分支随着提交操作自动向前移动图：

现在我们切换回 main分支看看：

git checkout main
git log --oneline --decorate

检出时 HEAD 随之移动图：

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

分支切换会改变你工作目录中的文件： 在切换分支时，一定要注意你工作目录里的文件会被改变。
如果是切换到一个较旧的分支，你的工作目录会恢复到该分支最后一次提交时的样子。 如果 Git 不能干净利落地完成这个任务，它将禁止切换分支。

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

git status
git commit -a -m 'made other changes'
git log --oneline --decorate

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

项目分叉历史图：

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

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

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

创建新分支的同时切换过去： 通常我们会在创建一个新分支后立即切换过去，这可以用 git checkout -b 一条命令搞定。