一、代碼提交規范化的目的

• 為了部門提交代碼信息格式規范化
• 為了更好的追溯代碼、篩選
• 為了更加快速的定位提交代碼所涉及的范圍和實現功能
• 為了后續代碼的Review、自動生成ChangeLog

二、代碼提交信息規范模板

本模板修改自《Angular代碼提交規范》,分為Header、Body兩大塊內容，去除Footer，這一部分我們并不常用

[Bug修復](4.27.10):http://jira.xyz.cn/browse/XYZDEV-9043

原因分析:需求內容不完整或錯誤

Header

1、提交類型

• 【新增功能】-【新的功能點、新的需求】
• 【Bug修復】-【修復的Bug:現網發散Bug、測試階段的Bug、驗收階段的Bug】
• 【文檔修改】-【只是修改了文檔:注釋、README.md等】.
• 【樣式修改】-【不影響代碼功能的修改:CSS樣式、代碼格式化等】
• 【代碼重構】-【代碼更改既不修復錯誤也不添加功能】
• 【性能優化】-【代碼更改可以提高性能】
• 【測試代碼】-【添加缺失測試或更正現有測試】
• 【編譯代碼】-【影響構建系統或外部依賴項的更改:build.gradle、package.json、Podfile等】
• 【持續集成】-【我們的CI配置文件和腳本的更改:Jenkinsfile等】
• 【回退更改】-【代碼回退提交更改】
• 【其他提交】-【除以上所有類型之外的提交更改】

2、涉及范圍

這里我們以版本號劃分范圍，此次提交代碼所涉及到的發布版本。如果涉及多個版本則以4.14.10~4.27.10表示

3、簡要描述

（1）如果提交類型是【Bug修復】,則簡要描述直接填寫Bug的JIRA或者Sentry鏈接
（2）如果提交類型是【新增功能】,則簡要描述填寫對應需求的JIRA鏈接或需求的詳細描述，如需求過于龐大，則應拆分成小的功能點提交代碼，便于Review人員審核,也有利于Bug的回溯。
（3）如果提交類型是其他類型，則簡要描述根據你的理解，盡量用簡短的文字描述出此次代碼提交的目的

Body

1、詳細描述

這邊的詳細描述，力爭語句表達清晰此次提交的代碼具體涉及的功能點、修改、原因分析等，如功能點很多則應使用序號列出代碼所涉及的功能點。如下所示

1、安心管選擇對象頁修改
2、家庭成員、車輛、房屋的列表、編輯、新增頁修改
3、安心管關系對象重定義

三、IDEA 插件集成

為了規范成員的提交代碼信息，我新寫了一個IDEA插件來幫助快速生成代碼提交信息模板。

提交

提交類型

歷史修復版本

設置頁

IDEA插件集成

目前已經提交IDEA插件市場，搜索Commit-Message-Create或者使用下面提供的Jar包，自行百度集成。

TM20190422162653.png

鏈接：https://pan.baidu.com/s/1NGZOryuDb_pe5YOOj3Ppxg

提取碼：wlj4