Git 代码分支规范

目的

俗话说:没有规矩,不成方圆。遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性,不会显得杂乱无章,管理困难。Git分支规范也是一样。当遵循了某种约定的Git分支,在代码提交以及多开发、多分支协同工作的时候,必须遵循这个规范操作,否则不予以提交、合并代码、提测、上线等操作。

适用范围

适用Git管理开发的所有项目


分支约定

Git Flow有主分支和辅助分支两类分支,通常主分支也被称为长期分支。

  • 主分支用于组织与软件开发、部署相关的活动;

  • 辅助分支组织为了解决特定的问题而进行的各种活动。

主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。

分支介绍

•    tag:

使用release发布生产成功后,三日之内把release分支合并到master上并打tag。

使用realase分支创建tag版本,使用tag进行线上部署

生产流水线自动打tag

•    master分支:

不接受commit,只接受来自realase分支的merge操作

分支必须开启分支保护,只有维护者可以操作

•    release分支:

可从test/master分支上拉取;

不接受commit,只接受来自对应test分支的合并操作;

普通开发人员不具有合并权限,需要管理员才能合并

release分支用于发布预生产环境部署;

上线成功后必须立即合并到master

release分支用于发布生产环境部署,上线完成后,禁止合并;

•    test分支

从master/develop分支拉取,用于测试环境部署

不接受commit提交,只接受来自对应develop的合并

•    develop分支:

从master/feature分支拉取,用于开发环境部署

不接受commit提交,只接受来自feature的合并

•    feature分支:

不限制从什么分支拉取,拉取代码时候版本号必须大于等于最新master的版本

可直接commit

一般不用于任何环境部署,特殊情况可以用于开发环境部署

禁止用于测试、预生产、灰度、生产部署

bug修复分支,也按feature分支规范和流程

•    hotfix分支

紧急bug修复分支,仅用于紧急的线上问题修复,普通bug修复还是使用feature分支规范

分支命名规则及对应环境

分支

命名规则

名称

环境

权限

master

master

主分支,保护分支,只接受merge 

-

保护

tag

 tag-{上线时间}-v{版本号} 

tag 如:tag-20220803-v1.2.0

-

只读

release

release-{时间}-{版本号}-{创建人} ;

 预上线分支;release-20220803-v1.2.0-liuyy 

预生产、生产

保护

test

test-{时间}-{功能描述}-{创建人} ;除了前缀,名称与develop一致

测试部署分支; test-20220803-superChargeV1-liuyy

测试

保护

develop

develop-{时间}-{功能描述}-{创建人}  ; 除了前缀,名称与feature一致

开发部署分支;develop-20220803-superChargeV1-liuyy

开发

常规

feature

 feature-{创建时间}-{功能描述}-{创建人} 

功能开发分支;feature-20220803-superChargeV1-liuyy

-

常规

hotfix

hotfix-{创建时间}-{bug描述}-{创建人}

紧急bug修复分支;hotfix-20220803-bugxxx-liuyy

不限

常规

分支规则正则:

--javascripttypescriptbashsqljsonhtmlcssccppjavarubypythongorustmarkdown

^(test|feature|develop|hotfix)-(20\d{6})(-\w+){2}$|^(release|tag)-(20\d{6})-v\d+(\.\d+){2}(-\w+){0,1}$

分支使用示意图

Git 代码分支规范_第1张图片

总结

1、一个上线需求一个feature分支,正常情况feature、develop、test、release分支是一一对应的

2、如果有多个需求需要合并上线,那么需要从develop分支开始合并,即多个feature对一个develop分支,但develop、test、release也还是一一对应的

3、除了feature分支外,所有分支都不接受commit,只接受合并

4、普通bug修复使用feature分支,流程一样

5、紧急bug修复走hotfix分支流程

6、所有上线的代码必须走完完整的develop、test、release流程

代码提交规范

  • 所有commit必须有注释,内容必须简洁明了的描述本次commit涵盖了哪些内容。严禁注释内容过于简单或不能明确表达提交内容的!

  • 合理控制提交内容的颗粒度,一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。

  • 提交注释字符数务必大于8, 尽量控制在60个字符之内。

建议参考规范:

示例

fix(首页模块):修复弹窗 JS Bug。

type(可选)表示动作类型,可分为:

  • fix:修复 xxx Bug

  • feat:新增 xxx 功能

  • test:调试 xxx 功能

  • style:变更 xxx 代码格式或注释

  • docs:变更 xxx 文档

  • refactor:重构 xxx 功能或方法

scope(可选) 表示影响范围,可分为:模块、类库、方法等。

subject(必须) 表示简短描述,大于8个字符,小于 60 个字,如果有编号的 Jira 号,建议在描述中加上。

你可能感兴趣的:(开发规范,git,java,github)