大厂都在用的Git代码管理规范

👉 这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料： 

• 《项目实战（视频）》：从书中学，往事上“练”

• 《互联网高频面试题》：面朝简历学习，春暖花开

• 《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题

• 《精进 Java 学习指南》：系统学习，互联网主流技术栈

• 《必读 Java 源码专栏》：知其然，知其所以然

👉这是一个或许对你有用的开源项目

国产 Star 破 10w+ 的开源项目，前端包括管理后台 + 微信小程序，后端支持单体和微服务架构。

功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号等等功能：

• Boot 地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

• Cloud 地址：https://gitee.com/zhijiantianya/yudao-cloud

• 视频教程：https://doc.iocoder.cn

来源：码农参上

• 分支命名

  • master 分支

  • develop 分支

  • feature 分支

  • test分支

  • release分支

  • hotfix 分支

• 分支与环境对应关系

  • 分支合并流程规范

• Git Commit Message规范

  • Angular Git Commit Guidelines

  • 简易版

  • type规范

  • 单次提交注意事项

• 配置.gitignore文件

• 其他

---

分支命名

master 分支

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

develop 分支

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

feature 分支

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

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

test分支

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

release分支

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

hotfix 分支

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

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

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro

• 视频教程：https://doc.iocoder.cn/video/

分支与环境对应关系

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

• DEV 环境（Development environment）：用于开发者调试使用

• FAT环境（Feature Acceptance Test environment）：功能验收测试环境，用于测试环境下的软件测试者测试使用

• UAT环境 （User Acceptance Test environment）：用户验收测试环境，用于生产环境下的软件测试者测试使用

• PRO 环境（Production environment）：生产环境

对应关系：

分支	功能	环境	可访问
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 分支

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud

• 视频教程：https://doc.iocoder.cn/video/

Git Commit Message规范

Git commit message规范指提交代码时编写的规范注释，编写良好的Commit messages可以达到3个重要的目的：

• 加快代码review的流程

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

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

Angular Git Commit Guidelines

业界应用的比较广泛的是Angular Git Commit Guidelines：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

• type：提交类型

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

• subject：简明扼要的阐述下本次 commit 的主旨，在Angular Git Commit Guidelines中强调了三点。使用祈使句，首字母不要大写，结尾无需添加标点

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

• footer: 描述下与之关联的 issue 或 break change

简易版

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

<type>(<scope>):<subject>

type规范

Angular Git Commit Guidelines中推荐的type类型如下：

• feat: 新增功能

• fix: 修复bug

• docs: 仅文档更改

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

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

• perf: 改进性能的代码更改

• test: 添加缺少的测试或更正现有测试

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

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

• delete：删除功能或文件

• modify：修改功能

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

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

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

• revert：回滚到上一个版本

单次提交注意事项

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

• 提交问题不要超过3个

• 提交的commit发现不符合规范，git commit --amend -m "新的提交信息"或 git reset --hard HEAD 重新提交一次

配置.gitignore文件

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

通用文件示例：

HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/

## STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache

## IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr

## NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/

## VS Code ###
.vscode/

# Log file
*.log
/logs*

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmd

其他

此外，还有一些其他建议：

• master 分支的每一次更新，都建议打 tag 添加标签，通常为对应版本号，便于管理

• feature分支、hotfix分支在合并后可以删除，避免分支过多管理混乱

• 每次 pull 代码前，提交本地代码到本地库中，否则可能回出现合并代码出错，导致代码丢失

---

欢迎加入我的知识星球，全面提升技术能力。

👉 加入方式，“长按”或“扫描”下方二维码噢：

星球的内容包括：项目实战、面试招聘、源码解析、学习路线。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）