Git代码管理规范

第第页Git代码管理规范分支命名

master分支

master为主分支，也是用于部署生产环境的分支，需要确保master分支稳定性。master分支一般由release以及ho（tf）ix分支合并，任何时间都不能直接修改代码。

develop分支

develop为开发环境分支，始终保持（最新）完成以及bug修复后的代码，用于前后端联调。一般开发新功能时，feature分支都是基于develop分支创建的。

feature分支

开发新功能时，以develop为基础创建feature分支。

分支命名时以

feature/

开头，后面可以加上开发的功能模块，命名示例：feature/user_module、feature/cart_module。

（te）st分支

test为测试环境分支，外部用户无法访问，专门给测试人员使用，版本相对稳定。

release分支

release为预上线分支（预发布分支），UAT测试阶段使用。一般由test或hotfix分支合并，不建议直接在release分支上直接修改代码。

hotfix分支

线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支。修复完成后，需要合并到master分支和develop分支。

分支命名以hotfix/

开头的为修复分支，它的命名规则与feature分支类似。

分支与环境对应关系

在系统开发过程中常用的环境：

DEV环境（Developmentenvironment）：用于（开发者）调试使用。

FAT环境（Feature（Ac）ceptanceTestenvironment）：功能验收测试环境，用于测试环境下的软件测试者测试使用。

UAT环境（UserAcceptanceTestenvironment）：用户验收测试环境，用于生产环境下的软件测试者测试使用。

PRO环境（Produc（ti）onenvironment）：生产环境。

对应关系：

分支功能环境可访问master主分支，稳定版本PRO是develop开发分支，（最新版）本DEV是feature开发分支，实现新特性

否test测试分支，功能测试FAT是release预上线分支，发布新版本UAT是hotfix紧急修复分支，修复线上bug

否分支合并流程规范

业界常见的两大主分支（master、develop）、三个辅助分支（feature、release、hotfix）的生命周期：

以上生命周期仅作参考，不同开发团队可能有不同的规范，可自行灵活定义。

例如我们团队在开发时，至少需要保证以下流程：

develop分支和hotfix分支，必须从master分支检出。

由develop分支合并到test分支。

功能测试无误后，由test分支合并到release分支。

UAT测试通过后，由release分支合并到master分支。

对于工作量小的功能开发（工时小于1天），可以直接在devolop分支进行开发，否则由develop分支检出feature分支进行开发，开发完后合并到develop分支。

GitCommitMessage规范

GitCommitMessage规范指提交代码时编写的规范解释，编写良好的CommitMessage可以达到3个重要的目的：

加快代码review的流程。

帮助我们编写良好的版本发布日志。

让之后的维护者了解代码里出现特定变化和feature被添加的原因。

AngularGitCommitGuidelines

业界应用的比较广泛的是AngularGitCommitGuidelines：

():

type：提交类型。

scope：可选项，本次commit波及的范围。

（sub）ject：简明扼要地阐述下本次commit的主旨，在AngularGitCommitGuidelines中强调了三点。使用祈使句，首字母不要大写，结尾无需添加标点。

body：同样使用祈使句，在主体内容中我们需要把本次commit详细地描述一下，比如此次变更的动机。

footer：描述下与之关联的issue或breakchange。

简易版

项目中实际可以采用简易版规范：

():

type规范

AngularGitCommitGuidelines中推荐的type类型如下：

feat：新增功能。

fix：修复bug。

docs：仅文档更改。

style：不影响代码含义的更改（空白、格式设置、缺失分号等）。

refactor：既不修复bug也不添加特性的代码更改。

pe（rf）：改进性能的代码更改。

test：添加缺少的测试或更正现有测试。

chore：对构建过程或辅助工具和库（如文档）的更改。

除此之外，还有一些常用的类型：

delete：删除功能或文件。

modify：修改功能。

build：改变构建流程，新增依赖库、工具等（例如webpack、gulp、npm修改）。

test：测试用例的新增、修改。

ci：自动化流程配置修改。

revert：回滚到上一个版本。

单次提交注意事项

提交问题必须为同一类别。

提交问题不要超过3个。

提交的commit发现不符合规范，gitcommit--amend-m"新的提交（信息）"或

gitreset--hardHE（AD）

重新提交一次。

配置.gitignore文件

.gitignore是一份用于忽略不必提交的文件的列表，项目中可以根据实际需求统一.gitignore文件，减少不必要的文件提交和冲突，净化代码库环境。

通用文件示例：

HELP.mdtarget/!.mvn/wrapper/maven-wrapper.jar!**/src/main/**/target/!**/src/test/**/target/###STS###.apt_generated.classpath.fact（or）ject.settings.springBeans.sts4-cache###（Intel）liJIDEA###.idea*.iws*.iml*.ipr###NetBeans###/nbproject/private//nbbuild//dist//nbdist//.nb-gradle/build/!**/src/main/**/build/!**/src/test/**/build/###VSCode###.vscode/#Logfile*.log/logs*#BlueJfiles*.ctxt#MobileToolsfor（Java）(J2ME).mtj.tmp/#PackageFiles#*.jar*.war*.ear*.zip*.tar.gz*.rar*.cmd

其他