release分支与master分支问题同步机制考虑

背景

对于OpenHarmony的分支管理现状的分析，发现主干分支大量合入含需求问题优化，release分支维护开发者，无法区别哪些合入会对release分支产生怎样的价值，进而无法决定是否需要合入release分支。同样的情况也出现在release bugfix同步到主干及其他release分支。

目标：

1、清晰的了解关键的bug介绍，影响。

2、清晰的了解关键的流程优化及内容。

为了实现上述目标，需要先了解OpenHarmony的开发模式，对症下药。

OpenHarmony开发模式

分支管理业界实践

Git Flow 的开发模式（业界应用最广泛的）

https://zhuanlan.zhihu.com/p/50063660

特点：release分支只做协助发布，问题合入使用。完成发布，打上主干的tag后，就删除该分支。

当某个版本出现关键问题时，需要在问题合入主干后，同时打上版本标签。

单主干的分支实践（Trunk-based development，TBD）

目前OpenHarmony，freebsd，Google等使用该开发模式。如下图所示，主线开发模型是同一个产品的所有的开发人员共享一个 trunk，开发人员可以有自己的私有分支，但所有修改最后都会回到主干，只有在 Release 时才会创建 Release Branch，由 Release Engineer 进行维护，发布分支是主干某个时点的快照，必要时通过 cherry-pick 从主干挑拣代码到发布分支。基于主干的开发的优点是保证了所有用户看到的都是同一份代码的最新版本，避免了合并分支时的麻烦，缺点是不适于瀑布开发模型，同时对开发人员和发布分支的维护人员的技术要求比较高。

缺点：采用这种分支策略可能碰到的最大问题就是某个分支上的bug修改内容往其它分支merge的时候出现的冲突。而且一旦发现一个bug，调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加。（ 来自 ）

commit 规范（当前还未遵循明显的模式）

一些建议

issue支持关联多个分支，码云当前不支持。

issue支持按代码仓库设置标签，支持标签的增删改查。

commit msg规范书写，如Angular commit msg规范。 不仅做一个合格开源开发者，也能同时减轻代码维护者的负担。 Angular commit msg规范 阮一峰这篇写的很详细：https://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html