git提交代码规范

Git提交代码规范

本规范大部分适用于规范研发体系所有软件工程师的Git提交

相关名字解释

• [SC] 表示第三方的 source code，比如框架代码，开源代码
• [NF] 表示新的 feature
• [IM] 表示功能改进等
• [BF] 表示修复 bug
• [EN] 表示提交的加密代码
• [Release] 发布版本

内容完整性要求

git 提交时必须说明本次操作的目的，尽量详细的说明修改内容，不允许使用 “fix、modify”等简单词汇进行备注，修复bug 时带上bug号如#2234

举个栗子

[NF]:大数据备份增加带宽控制
1

git 提交要求

• 一次代码提交，只包含一个 feature、一个bug或者一个改进。禁止将很多不相关的代码一次集中提交。
• 禁止代码的随意更改，不允许改动一个问题提交多次git
• 第三方代码提交：在提交时注明是哪一方提供的代码、来源、版本等信息如：[SC]: zip library 1.2.8 from http://zlib.net/
• feature 代码提交：在提交时要详细说明特性、设计实现的大致原理、相关的注意事项。提交时最好加上模块名如：[NF]:[模块名] + 注释
• 修复bug代码提交：提交时注明对应的bug编号，并对问题进行描述、问题的解决办法简要概述。
• 改进的代码提交：提交时需要对问题进行描述
• 提交代码时必须使用自己的git 账号，方便后续追踪代码的修改人

分支

• master 用来记录项目历史，以及对外发布
• develop 分支用于功能分支的集成。此分支上的bug修复，新开的分支需要用 bugfix/ 作为前缀，推荐使用前缀 + bug号: bugfix/7052；
• feature 用于新功能开发，从develop分支拉取。 定期或者需要的时候会出测试包，功能开发阶段性完成后，合并代码到develop时需要有测试报告以及代码评审
• hotfix 用于修复已经对外发布版本的bug修复, 从master分支拉，需要用hotfix/ 作为前缀，代码合并到master需要经过评审。
• release 为对外发布做准备，到既定时间（计划时间）从develop拉，这个分支只应该接收bugfix，文档准备等

合并bug的时候建议：

合并提交 并 删除源分支，保持 remote上干净，不会出现太多分支。