本文探讨了OpenHarmony的分支管理现状，分析了Git Flow与Trunk-based development两种开发模式，并针对OpenHarmony的特点提出改进建议。重点讨论了如何明确bug修复和流程优化，以及引入Angular的commit msg规范提升代码维护效率。
分支管理有关思考
文章目录
背景
对于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，开发人员可以有自己的私有分
最低0.47元/天 解锁文章
2007
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
