基于持续集成/发布的分支管理策略

经过了一段时间的探索和实践，我们最终确定基于持续集成/发布的分支策略如下图：

解释一下，

1.dev/0902代表9月20日要发布的开发分支；开发人员的提交全部提交到这个分支上。

2.rel/0902代表9月20日要发布的发布分支；由manager在发布日之前的一到两天由dev合并到rel分支。进行最终包集成。后续非严重问题不予合并。

3.hotfix发布之后，hotfix的commit进行cherry-pick到下一个dev分支

4.非严重的问题，在集成期间，提交到pre分支，最终会被merge到下一个版本的dev分支

图例：

这样的分支发布策略有如下几种优势：

1.方便定位崩溃。

根据线上的崩溃日志去定位对应版本的代码时，如果没有一个对应的版本分支，则代码很容易对应不上，排查起来很麻烦

2.方便基于发布版本创建hotfix。

我们hotfix是基于tinker的原理，需要有一个基带版本。基于这个发布版本分支继续

3.查询方便。

切到具体的版本，查询某处历史逻辑，会很方便。