版本与分支

    在我们的开发过程中需要对软件版本进行版本规划和管理，那么为什么需要规划和管理呢，又怎样进行规划和管理呢？

    其实，在正规的公司中，开发一款产品首先需要进行产品规划，即规划产品的针对性和功能。由于产品往往会有非常多的功能，所以需要先把产品的版本进行一个规划，往往再开发中先把基本功能实现，再通过功能迭代添加新功能。

    下图是一个产品的基本演进。

    首先，我们根据计划首先组织几个大牛进行产品架构，快速推出一个架构版本，并在版本库中建立0.1主分支稳定版，该版本要求实现软件的主要功能，打通数据通道。比如微博就需要有接收微博和发送微博的功能。

    master分支建立之后，将会在版本库中建立开发分支，以0.1版的代码为基础，开始进行功能迭代，即架构师会根据版本规划，列出每轮迭代需要实现什么功能，一般功能越基础安排越早进行迭代。比如，安排在1.0商用版之前需要实现10个功能，这些功能会经过优先级筛选安排在N轮迭代中开发，如果项目比较大，一般一轮迭代会持续一个月，迭代结束后会给管理层进行一次show case。

   在版本迭代过程中有可能会出现这么一种情况，产品经理and架构师发现有一个新特性不能确定是否可以完成，这时会单独列出一个特性分支，组织几个人进行开发，尝试实现该特性。这里既然是尝试的预研版本，当然也有失败的可能性。为了不影响开发进度，一般要求该特性开发的成败不会影响产品的发布。

    当开发人员进行1.0版开发的过程中，有可能会暴露0.1稳定版的bug，这时需要建立热补丁分支，进行bug修复，修复完并通过测试后，将会把代码合并到开发版，并把稳定版0.1升级到0.2版本，最后删除该热补丁分支。

    当特性分支完成开发后，需要把这些特性的代码也合并到开发分支上，然后删除该特性分支。

    待1.0所需的功能特性都完成后，将建立release分支，提交商用，在商用期间可能会出现一些bug，所有的bug会在该分支进行修复。待版本稳定后，将在master分支中建立1.0的稳定版，作为2.0版本开发的基础代码。

    之后，又会重复重复.....