release和master分支问题同步机制文章目录考虑release和master分支问题同步机制，实践背景OpenHarmony开发模式分支管理行业最广泛使用的Git Flow开发模式
背景
通过分析OpenHarmony的分支管理现状，发现主干分支的大量合并优化了包括需求在内的问题，而release分支维护开发人员无法区分哪些合并可以为release分支带来哪些价值，从而导致release分支的优化release bugfix与主干和其他release分支同步也可能发生类似的情况。
目标：
1、清晰了解关键bug的介绍、影响。
2、清楚了解关键流程优化和内容。
为了实现上述目标，首先需要了解开放健康的开发模式，进行对症治疗。
OpenHarmony开发模式行业实践Git Flow的开发模式(业内使用最广泛) https://zhi Hu.com/p/50063660
特点：发布分支只提供发布支持，问题结合使用。 发布完成并标记主干后，删除其分支。
如果某个版本遇到重要问题，则必须在将问题合并到主干后同时对其进行版本标签。
单主干网分支实践(Trunk-based development，TBD )目前已有开放硬件、自由软件、谷歌等使用该开发模式。 如下图所示，主线开发模型中同一产品的所有开发人员共享一个中继，开发人员可以有自己的专用分支，但所有修改最后都返回到主干，只有在Release的情况下创建Release Branch 由Release Engineer维护，发行分支是主干的某个时间点的快照，基于主干的开发的优点是(如果需要)通过cherry-，这可以确保所有用户看到相同代码的最新版本缺点是不适合瀑布开发模式，同时对开发人员和发布分支维护人员的技术要求较高。
缺点：采用这种分支策略时可能遇到的最大问题是，一个分支上的错误修复内容被合并到另一个分支时发生的冲突。 当发现错误时，检查该错误影响哪个分支的工作将根据要维护的发布分支的数量而增加。 (来自https://juejin.cn/post/6844904197763104775 )
commit规范(当前不遵循明显模式)一些建议的issue支持多个相关分支，而代码云当前不支持。
issue支持为每个代码仓库设置标签，并支持添加/删除标签重新评估。
Angular commit msg规格等commit msg规格书。 不仅可以成为合格的开源开发人员，还可以减轻代码维护者的负担。Angular commit msg规范
hldcs这个写得很详细。 https://www.Ruan Yifeng.com/blog/2016/01/commit _ message _ change _ log.html