gitflow的规范

背景：

总结一下，目前接触到的两种gitflow规范。

老版本gitflow流程：

master   分支是用于线上生产环境和预环境

develop  分支是开发分支，用于qa测试环境，新功能的开发以及bug的修复分支，都是已改分支作为起始点

feature,bug分支从分支命名上，没有按照feature/xxx,bug/xxx命名，而是以jira问题号命名，示例：section-1324_fix_bug_xxx,section-1299_feature_xxx

feature，bug处理完毕后，研发在开发环境自测无误，就会将分支合并到develop分支，代码上到develop后，测试会在qa测试，通过测试后，就可以将代码发布到master

这个git规范，最有特色的处理方式，是针对develop分支上的commit发布到master，不是通过合并直接合并develop到master，

而是通过cherry-pick命令实现的，这种方式可以很灵活的进行发布，发布前由产品经理会根据研发进度来整理当期需要发布的section问题号（由于某些feature临时测出了新bug，可以先不发），提供给研发，研发根据如下命令，来查找需要发布的commitid：

git log --merges --pretty=format:"%h %ad %s" | grep '\(section-435\)'

ps：–merges参数，能过滤掉非merge类型的commit

为啥要过滤掉非merged类型的commit，原因cherry-pick只能发布merged类型的commit；

这样做，确实灵活性高，但是流程复杂了，导致容易出错，主要是容易漏掉commit，导致线上代码和测试环境不一致，这个漏掉主要是因为git log找commit，可能找漏掉了，例如：你的同事骚操作，在develop分支上做了回滚后的提交操作，这个提交操作就不是merge类型的，导致git log找不到。

另外cherry-pick的执行，需要严格按照操按照时间线性的