如何使用Git做分支管理？

一、由头

    今天在微信公众号（程序员的成长之路）上看到了一篇文章，讲述一位5年的Java，居然对Git的分支管理毫不了解。我心想啊，我2年了，我也说不出个所以然了，所以就恶补了下，分享一下找资料之后，自己对Git分支管理的理解。

二、实际开发过程中分支管理

    1.master：主分支。创建项目自动生成，不可删除。

    2.hotfixes：紧急修复分支。版本发布后出现bug，需要紧急修复，在master分支上创建hotfixes分支，修复后代码会合并到develop和master分支。

    3.release branches：发布分支。在develop分支上创建，如果出现bug，可以在该分支上进行修复；如果是一些非严重bug，也可留到下个版本发布。该分支完成后合并到develop和master分支。

    4.develop：开发分支。在master分支上创建。

    5.feature branches：功能分支。在develop分支上创建。主要是开发某些功能，开发完成后，合并到develop分支。

三、整体理解（小故事）

    1.小明需要开发一个项目，于是用Git创建了一个仓库，初始化后仓库中有一个master分支。

    2.第二天，小明在master分支上创建了一个develop分支，并叫上小黑、小白一起开发项目。

    3.小白在开发新功能之前，在develop分支上创建了一个feature分支，经过2小时的开发测试后，实现了功能，于是他把该分支合并到了develop分支，并删除了该分支。

    4.第三天，小明三人都开发好了负责的功能，于是小明在develop分支上创建release分支，设置为1.0版本。发布到测试环境后，小蓝进行了项目的覆盖测试。测试过后，发现了2个bug，于是跟小明他们说明。

    5.小明了解后，发现其中有一个bug比较严重，于是直接在release分支上进行修复。对于另一个bug，由于不影响用户体验，所以决定留到下个版本再发布。于是把这个release版本合并到develop和master分支上，最终master上的最新版本作为项目的1.0版本，发布到生产环境。

    6.在发布上线后，很多用户开始使用，比较细心的用户又发现了一个bug，然后通过客户电话投诉到公司，公司马上找到小明，让他赶紧解决。

    7.小明只能尽快想办法解决了，他在master分支上创建了一个hotfix分支，经过1小时的努力，终于把bug修复好了，于是把该分支合并到develop和master分支，而master上的分支作为项目的1.1版本发布。

    8.经过几天的用户使用和市场调研，小明发现需要增加一些新的功能，于是小明4人又开始开发测试，把之前延迟上线的功能和新功能一起完成了。

    9.小明又在develop上创建了release分支，并设为2.0版本，发布到测试环境。经过小蓝的覆盖测试发现没有bug，这次很顺利，于是小明一行人愉快地把版本发布到了生产环境。