1、Git代码提交注释规范

需求类Git注释

需求注释格式是：需求#{需求ID}：开发人员填写的注释内容

例如：需求#123456 API接口开发和提供

Git命令：

$ git commit -a -m "需求#123456 API接口开发和提供"  

效果类似如下示例：

提交后，需求状态自动更新为：研发中、自动上屏到需求备注（方便code review）。

问题类Git注释

格式是：bug#{问题ID}：开发人员编写的注释内容或问题原因

例如： bug#123456 这里可以填写修复的原因

Git命令：

$  git commit -a -m "bug#123456 这里可以填写修复的原因"

效果如下示例：

提交后，问题状态自动更新为：已解决、自动上屏到问题备注（方便code review）、邮件通知问题创建人员并推送钉钉群消息。

上面的需求和Bug提交规范，可以自动和YesDev的需求、Bug进行关联。

2、开发提测新模板

新提测模板请参考：《开发提测模板》

邮件标题：XXXX提测申请

项目链接：// 填写YesDev对应的项目链接或需求链接

开发分支：// 粘贴Git仓库分支链接

code review：// 分支对比链接，以及审计负责人

测试环境：// 填写测试环境的域名或APP安装包链接或小程序体验二维码

开发人员：// 参与本次开发的人员名单（可以进一步补充每个模块的主要负责人）

提测内容：// 原来的提测内容

影响模块：// 原来的影响模块

3、线上故障复盘模板

可以参考YesDev给出的故障复盘文档模板进行复盘，包括：故障标题、故障描述、故障影响及损失评估、处理过程、故障原因、后续改进措施等。

4、YesDev协作流程

1、面向产品经理和需求方

如何分类提需求？

1）常规迭代需求，添加需求或通过Excel导入，由技术负责人 创建项目并进行关联需求，评估工时，排期开发

2）紧急需求，需求方/产品经理和技术负责人沟通确认后，追加需求到已经排期的项目中，并且邮件同步发出

3）专项需求，创建项目后，维护项目需求，并指派需求给技术负责人

4）小改进需求，通过 问题-改进，进行单独提交，非技术问题，属于产品需求的小改动，例如：修改文案、更换图片或链接等

如何查看最新开发进度？

1）通过项目的详情页，查看项目进度和需求进度

2）在需求详情页，通过查看需求的代码提交记录，查看开发动态

3）通过 需求排期，查看当前最新的需求排期计划和迭代进度

4）通过每周的需求KPI邮件《每周需求迭代汇总》定时接收需求迭代的周记录，发送时间支持可配置

5）通过邮件、钉钉群消息，接收相关的需求流转新动态，例如：需求已完成、需求已上线等

6）通过钉钉群 【发布群】上线发布专用群，接收最终发布上线的通知，可以和YesDev进行集成

7）通过项目排期、提测邮件等，接收项目迭代汇总的信息

2、面向研发团队

如何流转需求？

1）根据需求，评估开发任务、工时、和预计完成的时间，在每周一之前形成自己的周工作计划

2）完成任务后，及时将任务状态改为DONE

3）开发过程中，提交代码时，按需求注释规范提交Git代码

4）需求完成或上线后，人工更新需求状态为：已完成/已上线

如何流转问题/Bug/故障/工单/改进？

1）问题解决后，将问题状态改为：已解决，并补充原因

2）问题重开后，重新修复后，将问题状态重新改为：已解决，并补充原因

3）可以按问题注释规范，提交Git代码，会自动更新问题状态为：已解决，并通知对方

4）遇到紧急的故障，应立即响应并处理，按“先止损-后定位-再排查-改代码-发布修复-最后复盘”顺序处理

如何统筹推进项目？

1）进行产品需求评审后，将已确定的需求，创建并关联到指定项目

2）分配需求到技术人员，各自拆解并评估任务和时间

3）汇总项目排期，发出项目排期邮件，如有需求，每天或每周或定时汇总重要项目的进度、风险和进度

4）关注每周的项目整体汇总邮件

3、面向测试部门

如何流转开发过程中发现的Bug？

1）在指定项目详情页，添加新问题到此项目，问题类型选择：Bug，并指派给技术人员

2）问题修复并验收后，将问题状态改为：已关闭，若依然有问题则改为：重开，并填写原因

如何处理线上故障？

1）发现故障后，第一时间在群里同步或现场沟通

2）同步创建故障单，并交给技术人员在故障处理完毕后补充编写

如何规划测试用例和测试计划？

1）可以创建或导入测试用例

2）可以创建测试计划并关联到指定项目

3）在测试计划，可以自动汇总并整理测试报告

4）可以定时接收每周的测试质量汇总邮件，跟踪每周的线上故障、工单等SLA服务水平

5、技术文档编写规范

针对重要的需求、核心功能、以及复杂的项目，可以按以下技术文档模板编写，以便进行技术评审。

开发分支：

// git的仓库分支

修改范围：

// 本次修改的页面、或新增的API接口等

技术设计：

// 核心的UML图，例如：时序图、泳道图、数据模型、架构图、流程图等

自测结果：

// 针对页面、接口、不同业务规则的自我验证，提供单元测试、链接、数据库截图以及其他材料证明

参考资料：

// 外部参考资料，例如XXX开放平台XXX接口