Git系列文章（6）：Git分支（2）

在开始今天的内容之前，对昨天分享的分支的创建和切换补充几张图。以这次Git分享工程为例：

1. 使用git log --graph --pretty=oneline查看提交列表

$ git log --graph --pretty=oneline
* cea42ba80f87808fdefcef6e3e0a10b87996829d (HEAD -> master, origin/master, origin/HEAD) feat: 完成20210205分享内容
* ab3fcd3e160c468ebaa02bcba57634214ea98623 feat: 完成20210204分享
* 3af1c4ea1c38c8a83de4b5505d3a804ec0580071 feat: 完成20210203内容分享
* 3037962efb685ca51f6e64d1b2b988df92f2c444 修改README信息
* 7a74d5e9c56b43540109a0a07662946397268497 feat: 完成20210202阅读分享
* 39aeaeb79ba70f5381f4bbd8a90505e228fd3268 feat: 完成20210201分享内容
* 1af7734f9fd6fcfb2cf683c27465f6cad40adda9 20210201公司电脑提交
* ee8c2d1fb59e2230e1c3956798d9655109ca0223 Initial commit

2. 根据上面的输出，可以得到下图表示的逻辑示意图，其中HEAD、master与最新的一次提交对象的关系， 在昨天的分享也谈到过了

3. 使用命令git branch example创建分支时，会创建一个新的指针，也是指向当前最新的提交对象，此时提交对象的追踪链如下图所示

4. 使用命令git checkout example切换到example分支，此时HEAD指针引用example分支

5. 切换分支后，在当前的example分支，编辑文件，并提交至版本仓库：

6. 使用命令git merge example将example分支提交的内容合并至master分支

7. 使用命令git log --graph --pretty=oneline，查看此时的提交链

$ git log --graph --pretty=oneline
*   ffc1c1a1cc889f821cf74de4abe6e470e7c2f737 (HEAD -> master) Merge branch 'example' into master
|\
| * ec25b41c3dfa3e189a4cfa8fa2922c534ebded58 feat: 完成部分20210206分享内容
* | 16749a4b0c62ac70b680bc4b53cad9d293cf0eda feat: 修改README.md
|/
* cea42ba80f87808fdefcef6e3e0a10b87996829d (origin/master, origin/HEAD) feat: 完成20210205分享内容
* ab3fcd3e160c468ebaa02bcba57634214ea98623 feat: 完成20210204分享
* 3af1c4ea1c38c8a83de4b5505d3a804ec0580071 feat: 完成20210203内容分享
* 3037962efb685ca51f6e64d1b2b988df92f2c444 修改README信息
* 7a74d5e9c56b43540109a0a07662946397268497 feat: 完成20210202阅读分享
* 39aeaeb79ba70f5381f4bbd8a90505e228fd3268 feat: 完成20210201分享内容
* 1af7734f9fd6fcfb2cf683c27465f6cad40adda9 20210201公司电脑提交
* ee8c2d1fb59e2230e1c3956798d9655109ca0223 Initial commit

3 分支的基本操作

3.1 基本分支的操作

Git中基本的分支操作与上述一列表中描述的逻辑相差不大。在每个开发迭代的中后期，经常会遇到这种情况：

1. 基于master分支部署了一个正式版本，但突然测试人员反馈会一个紧急的Bug需要去处理，这是可以从当前的master分支的基础上创建一个分支用来修复这个Bug，除了用上面提交的git branch issue202命令和git checkout issue202命令以外内，Git也提供了一个简短的命令git checkout -b issue202来实现上述效果，最终得到的示意图如下：

2. 这个Bug可能比较难解决，你提交了多次代码，这时候的第1步创建的分支的指针也会相应的前移

3. 在Bug还是一筹莫展的时候，项目经理突然提醒你已发布的版本中有个致命的问题需要马上解决，这时候，你要使用git checkout master返回主分支，并再创建一个hotfix分支来解决这致命的问题。这时候请注意，这时候请注意，这时候请注意(重要的事说3遍哈)，在切换分支之前，如果工作区或者暂存区中存在没有提交的更改，并且这些更改和你要切换到的分支有冲突，则Git不会允许你切换分支，因此，在切换分支时，最好保持一个干净的工作区，或者使用储藏或者修订的方法来绕过这个问题

4. 紧急Bug修复后并且通过测试，可以将代码提交到master分支用来部署新版本

5. 在返回issue202分支之前呢，可以先删除hotfix分支，使用的命令是git branch -b hotfix

6. 在issue202分支上继续完成Bug的修复工作，但此时需要注意的是，当前的issue202分支上并不存在之前hotfix的内容。

3.2 基本的合并操作

完成issue202分支上的工作内容，切换至master分支，使用git merge issue202将issue202分支的内容合并至master分支。

虽然和之前将hotfix分支的内容合并至master时使用的命令时一致的，但是背后的流程是不一样的。对比3.1节中第3和第4步内容的图片可以清楚的看到，这种类型的合并，只是将master分支向前移动了。这种类型是什么类型呢？概括来讲，当把一个分支A的内容合并值分支B上，如果分支A和分支B的共同祖先是分支B，那么这种合并，只需要将分支B的指针前移。

如果像刚刚提到的将issue202分支合并至master分支，通过3.1节中第5步中的图，可以了解到，这时候的master分支和issue202分支的共同祖先是早先的某个提交对象，这种类型的合并将会涉及到“三方合并”，这里的“三方”指的是：master分支指向的提交快照、issue202分支执行的提交快照以及两者的父提交快照。“三方合并”的结果将会创建新的提交快照，具体的示意图如下：

提交接受以后，可视情况删除issue202分支：git branch -d issue202。