Git 的原理与使用（中）（一） -阿里云开发者社区

Git 的原理与使用（上）中介绍了Git初识，Git的安装与初始化以及工作区、暂存区、版本库相关的概念与操作，本文接着上篇的内容，继续深入介绍Git在的分支管理与远程操作方面的应用。

五、分支管理

1.理解分支

分支是Git的杀手级功能之一。

它就像是科幻电影里面的平行宇宙，当你正在电脑前努力学习C++的时候，也许另一个平行宇宙里的另一个你正在努力学习JAVA。这两个平行宇宙互不干扰，而在某个时间点，它俩发生了合并——于是，你既精通了C++，又精通了JAVA！

在版本回退章节里我们已经知道，Git会把每次提交串成一条时间线，这条时间线就可以理解为是一个分支。截止到目前我们的Git仓库里中只有一条时间线，这个分支叫主分支，即master分支（也叫main分支）。

然后再来理解一下HEAD。HEAD严格来说指向的不是“提交（commit）”，而是当前所在的分支，而分支才是指向“提交（commit）”的。比如当前我们所在的分支是master，那么HEAD指向的就是master，master指向的才是“提交”。如下图所示：

每次执行commit操作，master分支都会向前移动一步以指向最新的“提交”。这样，随着你不断commit，master分支的线也会越来越长。而HEAD则一直指向指向当前分支不变，即现在我们所在的master分支。

可以通过

git cat-file -p <commit ID>

命令来查看提交信息：

2.创建分支 branch

如何查看当前本地仓库中已有的所有分支？

在工作目录下执行

git branch

命令，系统就能为我们打印出当前本地仓库中有哪些分支：

hyb@139-159-150-152:~/gitcode$ git branch #查看当前本地所有分支
* master    # 显示结果

这里查询到当前本地仓库中只有一个master主分支。

在我们创建本地仓库时，git会自动给我们创建出一个master主分支。master前面有一个 * ，*master 既表示master是当前的工作分支，也表示master分支正在被HEAD指针所指向。

关于HEAD：

HEAD不仅可以指向master主分支，也可以指向其它任意分支。

被HEAD指向的分支是当前正在工作的分支。由于之前我们的HEAD一直指向的是master分支，因此add操作、commit操作都是在master主分支上完成的。

为了演示多分支的情况，这里我们来创建第一个新的分支dev，对应的命令为：

git branch <分支名>

hyb@139-159-150-152:~/gitcode$ git branch dev #新建分支dev
hyb@139-159-150-152:~/gitcode$ git branch
  dev
* master

当我们创建新的分支后，Git 便新建了一个指针叫 dev。而 *HEAD 表示当前的 HEAD 仍然指向 master 分支，并没有发生变化。

也就是说，单纯的创建分支，是不会自动切换分支的。

# 打印一下HEAD指针的内容，可见HEAD指向的还是master
hyb@139-159-150-152:~/gitcode$ cat .git/HEAD
ref: refs/heads/master

此时，cat一下dev和master的内容，会发现它们两个指向的是同一个修改（即commit Id），这是因为dev分支是站在当前的版本去创建的，所以dev分支初始情况下也指向了最新的提交：

一张图总结：

3.切换分支

我们要想在dev上进行操作，就必须把dev分支当作工作分支。那如何切换到dev分支下进行开发呢？使用

git checkout <分支名>

命令即可完成切换。示例如下：

执行 git checkout dev切换分支后，HEAD就指向了dev，表示我们已经成功地切换到了dev上。随后，我们在dev分支下修改ReadMe文件，在末尾新增了一行内容 aaa on dev branch，并进行了一次提交操作。

现在，dev分支的工作完成，我们切换回master分支：

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'

切换回master分支后再查看ReadMe文件内容，此时发现ReadMe文件中刚才新增的内容不见了：

而再切回dev查看，刚才新增的内容又有了：

为什么会出现这个现象呢？

我们来看看dev分支和master分支的指向，发现dev和master两者此时指向的提交已经不一样了：

hyb@139-159-150-152：~/gitcode$cat.git/refs/heads/dev
bdaf528ffbb8e05aee34d37685408f0e315e31a4    # dev和刚创建时相比已经发生了改变
hyb@139-159-150-152：~/gitcode$cat.git/refs/heads/master
5476bdeb12510f7cd72ac4766db7988925ebd302

进一步的，可以通过命令

git cat-file -p bdaf528ffbb8e05aee34d37685408f0e315e31a4

来查看此时dev所指向的提交的详情。查询到的详情中，parent关键字标识了当前commit的上一个commit是哪一个。可以看到，dev当前指向的上一个指向，正是刚创建dev时dev的指向。因为我们是在dev分支上提交的，所以dev会指向最新的提交；而master分支此刻的指向并没有改变（正如两个平行宇宙之间彼此独立的）。

master的视角下，当然就看不到在dev下的提交了，因此在master和dev两个分支下的ReadMe文件内容会有差别。

4.合并分支

为了在master主分支上能看到新的提交，就需要将dev分支合并到master分支。

使用

git merge dev

命令，示例如下：

git merge命令用于合并指定分支到当前分支。合并后，master分支上就能看到dev分支提交的内容了。此时的状态如图如下所示：

仍然可以用 cat .git/refs/heads/master命令和 cat .git/refs/heads/dev命令分别查看master和dev的指向，此时发现二者指向再次相同，dev中存储的commitID也被同步给了master。

By the way，细心的朋友可能注意到，刚才merge操作后，结果其实有些特殊：

这里的 Fast-forward 代表“快进模式”，它是Git分支合并的一种方式。快进模式意味着合并的方式是直接把master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都是Fast-forward，我们后面会讲其他方式的合并。

5.创建、切换、合并分支流程图

1、创建新的dev分支。

2、git checkout dev：切换至dev分支。

3、在dev分支上commit。

4、切换回master分支，git merge dev

6.删除分支

合并完成后，dev分支对于我们来说就没用了，那么dev分支就可以被删除掉。删除分支的命令为：

git branch -d <分支名>

注意，如果当前正处于dev分支下，是不能删除dev分支本身的：

hyb@139-159-150-152：~/gitcode$ git branch
*dev
 master
hyb@139-159-150-152：~/gitcode$ git branch -d dev
error：Cannot delete branch 'dev' checked out at'/home/hyb/gitcode'

要删除当前分支，只能先切换到其他分支下，再执行删除操作，如：

hyb@139-159-150-152：~/gitcode$ git checkout master
Switched to branch 'master'
hyb@139-159-150-152：~/gitcode$ git branch -d dev
Deleted branch dev(was bdaf528).
hyb@139-159-150-152：~/gitcode$ git branch
* master