发布部分新特性

问题引入

新特性测试通过后发布到开发版进行内部体验，有些特性会最终发布到正式版给用户，有些不发布甚至丢弃。于是，正式版发布就面临只发布开发版某些新特性的问题。

版本管理规范

项目至少会存在三类版本：

开发版，也称内部体验版，功能特性开发测试通过后先发布到开发版

正式版，用户使用的版本，功能特性是开发版的子集

特性版，某个功能特性的版本，测试验收通过后发布到开发版，也可能丢弃

基于项目的版本管理规范，代码也需要制定相应的管理规范。

master分支，对应正式版，git仓库创建后默认创建master分支，它的代码来自于develop分支的合并

develop分支，对应开发版，可直接在该分支上修订bug，也可以创建特性分支开发新特性，新特性测试通过后合并到develop分支

feature1、feature2分支，对应特性版，新特性开发测试体验使用

develop分支经过多次修订bug、新特性合并后，要发布正式版时面临两种发布场景：发布所有新特性、发布部分新特性。发布所有新特性，使用merge命令。发布部分新特性比较麻烦，怎么做呢？

发布部分新特性

新特性开发设计时，就需要考虑支持特性可配置发布，可以通过定义某个宏来控制特性代码是否编译，也可以通过配置文件开关来控制特性的代码是否运行。通过开关控制特性是否发布，需要架构设计良好扩展性的支持。

然而，还是会面临一些场景无法通过配置开关来控制，比如原有特性进行优化，优化涉及多个产品，而且存在兼容性问题。这时发布正式版需要从develop分支挑选部分提交合并到master分支，挑选合并使用git cherry-pick命令，cherry-pick命令会计算此次提交变更的代码，应用到master分支。如果要挑选的分支是一次merge（比如feature2合并），因为有2个父节点，cherry-pick不知道要与哪个父节点比较，所以挑选merge提交时，需要增加-m选项指定父节点的索引（索引从1开始）。比如命令：git cherry-pick –m 1 260c2f8，合并260c2f8提交，指定父节点为1。