RnD-Codex集成工作流程
编码命名约定
➖ 帕斯卡命名法👉 类和方法
➖ 驼峰式命名法👉 变量和函数名称
➖ 蛇病例👉 文件名和变量标识符
➖ 烤肉串箱👉 HTML属性和CSS类
➖ 大写字母👉 常数和计数
➖ UPPER_SNAKE_CASE👉 常数和环境变量
Git分支命名约定
代码流分支
➖ 开发（dev）
所有新功能和错误修复都应该提交给开发部门。
➖ QA/测试（测试）
包含所有准备进行QA测试的代码。
➖ 暂存（暂存，可选）
它包含经过测试的功能，利益相关者希望在投入生产之前，这些功能可以用于演示或提案。
➖ 大师（Master）
如果存储库已发布，则生产分支是显示的默认分支。
临时分支机构
➖ 特性
新模块或用例的任何代码更改都应该在功能分支上完成。此分支是基于当前开发分支创建的。当所有更改都完成时，需要一个Pull Request/Merge Request来将所有这些更改提交给开发分支。
例子
特征/AZURE-1234
功能/AZURE-5678
➖ Bug修复
如果从功能分支进行的代码更改在发布、sprint或演示后被拒绝，则应在bugfix分支上进行任何必要的修复。
例子
错误修复/AZORE-1234
错误修复/AZORE-5678
➖ 热修复
如果需要修复阻止程序、执行临时补丁或应用应立即处理的关键框架或配置更改，则应将其创建为修补程序。它不遵循预定的代码集成，可以直接合并到生产分支，然后再合并到开发分支。
例子
修补程序/禁用端点零日漏洞
修补程序/增加缩放阈值
➖ 实验性
任何不属于发布或冲刺的新功能或想法。
例子
实验/黑暗主题支持
➖ 构建
专门用于创建特定构建工件或执行代码覆盖率运行的分支。
例子
build/ablue指标
➖ 发布
用于标记特定发布版本的分支。
例子
发布/app-1.0.0
➖ 合并
用于解决合并冲突的临时分支，通常在最新开发和功能或修补程序分支之间。如果需要合并、验证和最终确定多个开发人员正在开发的功能的两个分支，也可以使用此功能。
例子
merge/dev_lombok重构
合并/组合设备支持