Git的艺术—分支管理

腾讯工蜂Git：基于Git的企业级协作开发解决方案，腾讯未来研发关键系统

https://code.tencent.com

腾讯工蜂用户：赵秀雯

前言

Git的开发者—— Linus Benedict Torvalds，22岁就创建了Linux系统，发展到2005年的时候，用了仅两周的时间写了一个分布式版本控制系统，也就是Git！向这位天才致敬。

在管理项目代码过程中，不知道大家有没有遇到这样的问题，这里举个例子：平台首页要开发 A 功能，因此修改了 index.css 这个文件，把文件提交到 SVN 同步给前端开发后，前端开发可以继续折腾 A 功能的技术实现了；在 A 功能的开发阶段，又接到了外网反馈的一个紧急 bug，于是马上修改了 index.css 。在即将要发布的时候，测试发现首页某些模块的效果却全乱套了。

原来，是因为 index.css 里面集成了 A 功能的代码，但因为 A 功能还在开发阶段没有上线，因此影响了现有的首页。本来开开心心地以为修改了一个 bug，却带来了另一个 bug，于是原本打算晚上去网吧吃鸡的计划泡汤了，只能乖乖地留下来加班了。

怎样能够避免这种情况发生呢？马上你的脑回路给你提供了下面这几种选择：

a. 乖乖地把 index.css 版本回退到 A 功能的上一个版本，修复外网 bug 发布后，再继续把 A 功能的相关代码重新合并到 index.css 里给前端开发继续开发；

b. 把带有 A 功能的文件重新命名为 index2.css，现网用的文件依然是 index.css，紧急 bug 修复的时候同时修改 index.css 和 index2.css；

c. 老子不干了，今晚就是要去吃鸡。

a 选项候因为版本的回退会不会给正在进行的 A 功能开发造成影响呢？b 选项修复的时候却需要修改两份文件，并且可能针对一个页面一份样式在本地却存在 index.css、index2.css、index3.css...... c 选项，确定你今晚能吃鸡，明天还能好好地待在公司吃免费早餐？

废话少说（虽然铺垫得够长的），为了完美解决上述的问题，这里主要要介绍Git的分支管理。

Git是什么？

一句话概括，Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。因为项目的历史问题，之前一直代码版本控制系统一直用的都是 SVN 。而下面的 SVN 和 Git 的区别，是你需要知道的：

1. SVN 是集中式的，Git 是分布式。

2. SVN 是把内容按文件方式存储，而 Git 是按元数据方式存储。

3. Git 分支和 SVN 的分支不同：分支在 SVN 中一点不特别，就是版本库中的另外的一个目录。

4. SVN 有全局的版本号，这样子你就可以根据版本号知道每次提交的先后顺序了，但 Git 没有。

5. Git 的内容完整性要优于 SVN：Git 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。

Git的分支管理

一、 分支简介

关键词：master、HEAD、指针

当创建 Git 时，系统会默认创建一条分支，通常我们默认这条分支为叫主分支，即 master 。前文有提到，Git 是按元数据方式存储，保存一系列不同时刻的文件快照。master 其实是一个指针，它会在每次的提交操作中自动向前移动，保证指向在分支上最后提交的一次内容。

而当你新建另一条分支时，Git 为你创建了一个可以移动的新的指针。比如，创建一个 featureA 分支。如图一，master 分支上已有多个提交记录，最新一次提交为 M2 。此时在当前的提交对象上创建一个 featureA 分支，也就有了新的指针指向 M2。当我们切换到 featureA 分支上时，会有一个名为 HEAD  的特殊指针，它始终指向当前所在的分支上。凭着它，我们就知道目前的所有操作是对哪个分支进行修改了。

二、分支开发实操

关键词：创建分支、切换分支、合并分支

为了避免文章开篇提到的把文件提交前发现影响了外网的样式时的情况，可以约定只在 master 分支上保留完全稳定的代码——即仅仅是已经发布或即将发布的代码。而每次开发新功能是另起分支来开发，这些分支不必保持绝对稳定，适合多个功能同时进行开发但互不影响，一旦达到了稳定状态，就可以被合并入 master 分支了。这样，就可以确保这些已完成的特性分支能够通过所有测试，并且不会引入更多 bug 之后，合并入主干分支中，等待下一次的发布。

以下用图解 Git 分支管理如何解决文章开篇的问题：

（1）目前首页的稳定版本为 M2 ，即 master 指针指向的对象。在 M2 上我们创建一条名为 featureA 的分支进行开发，开发出 M3 版，因为操作是在 featureA 分支上，并不会污染现网的样式。

（2）突然遇到了一个需要马上修复的外网 bug，于是新建 bug 分支，修复验证后切换到 master 分支合并成为 M4 并发布，因此此时 HEAD 指针指向的是当前的分支 master 。

（3）A 功能终于开发完毕要上线了，但因为 A 功能是在主干 M2 版本上做的，此时还需要在主干上将主干最新的版本 M4 和 M3 合并成为 M5 版本，当然，在合并的过程中，发生代码冲突是很常见的，毕竟版本开发的时间节点不一样，解决冲突也是代码版本管理的一个大学问，但这里不展开讨论，之后有机会可以再一起探讨写篇新的文章嘻嘻。于是 master 和 HEAD 指针都指向了 M5。而 featureA 和 bug 分支，可以根据项目需要考虑删掉。

通过 Git 的科学化代码管理，我们能够既不影响开发新的功能，也能快速迭代版本，并且还能通过 Git 的记录追溯到任何一个版本上。 

总结

本文主要通过一个例子来讲述 Git 的分支管理概念，并没有提到任何 Git 的命令，因为概念清楚了，也就可以快速地在命令表中查到自己需要哪条命令了。Git 的分支管理在多人共同开发一个项目上的优势尤其明显，如果大家都在主干上开发，那代码将变得不堪入目。一言总结，Git 也就是一个工具，用好了它将帮助我们提高工作流程的科学性以及效率，Git 是一个好东西，希望大家都能拥有它 : ）

扫描以下二维码，研发管理从此高效、轻便、可靠

小广告