git提交代码规范

Git提交代码规范 本规范大部分适用于规范研发体系所有软件工程师的Git提交 相关名字解释 [SC] 表示第三…

Git提交代码规范

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

相关名字解释

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

内容完整性要求

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

举个栗子

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上干净,不会出现太多分支。

本文来自网络,不代表软粉网立场,转载请注明出处:https://www.rfff.net/p/1992.html

作者: HUI

发表评论

您的电子邮箱地址不会被公开。

返回顶部