代码提交规约

本项目采纳 DevOps 方法，致力于提高开发效率，加强团队之间的协作与沟通，以及快速响应操作。

流程规定

开发流程设计旨在确保每个功能点都能够得到充分理解和有效实施，同时保证项目整体进度符合预期。

• 工单管理：项目管理者将根据功能需求创建工单，并分配给相应的开发者。每个工单都详细描述了功能点的需求，开发者应仔细阅读并理解工单内容。如有疑问，应及时在工单中提问或请求帮助。「新任务接收到后，请各位开发者回复确认！避免遗漏任务点」
• 开发与代码审查：开发者在完成对工单的理解后，开始在feature分支进行代码编写。编码完成后，通过创建Pull Request来请求将代码合并到master分支。项目管理者或指定的代码审查员将对代码进行审查，确保代码质量和功能实现符合要求。
• 自动化部署：master分支的更新将触发自动化部署流程，通过Jenkins等CI/CD工具自动部署到测试环境，以便进行集成测试和性能测试。这一流程确保了代码的稳定性和可部署性。
• 漏洞修补与补丁更新：在项目开发过程中发现的任何漏洞都将通过创建新的fix/patch分支来进行修补。修补工作完成后，同样需要经过Pull Request和代码审查流程，确保补丁的正确性和稳定性。

分支规定

该部分内容前端与后端规定一致

项目定义了三条主要分支：master, feature, fix/patch。

• 主分支(master) ：代表项目的当前稳定版本，用于生产部署。
• 功能开发分支(feature) ：用于新功能的开发。每个新功能应在单独的feature分支上进行开发，待功能完成并通过审查后，再合并回master分支。
• 修补分支(fix/patch) ：用于修复发现的漏洞或进行必要的补丁更新。分支命名需遵循fix-工单ID或patch-工单ID的规则，以便追踪和管理。

其中 master 分支禁止开发者直接推送至仓库。对于所有的新业务代码请在 feature 分支编写，业务逻辑完成后，使用仓库功能 Pull Request(合并请求) 将代码往 master 分支合并；若在 master 分支下出现漏洞情况，按需创建 fix/patch 分支（该部分分支有命名要求），修补完成后提交 Pull Request(合并请求) 至 master 分支。

除此之外，请注意，feature 分支和 fix/patch 分支不可随意合并，避免后期造成代码混淆难进行业务状态跟踪。

问题处理

对于开发过程中遇到的问题，鼓励开发者首先尝试在工单内解决。如果问题超出了单一工单的范围，或者是跨功能点的，开发者可以创建新的工单来描述这些问题。新工单应明确问题的性质、影响范围，并指定负责人或相关协作者。

问题请各位开发者务必描述清楚！！！