前言

遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性，不会显得杂乱无章，管理困难。Git分支规范也是一样。当遵循了某种约定的Git分支，在代码提交以及多开发、多分支协同工作的时候，必须遵循这个规范操作，否则不予以提交、合并代码、提测、上线等操作。对于使用Git作为源代码管理工具的项目，如何使用Git工具及标准的工作量进行规范说明。

Git使用流程

设置用户签名

刚进公司，肯定是先初始化个人的用户签名
用户名一般是你的 “姓名” 。
邮箱就是公司给你的邮箱。

1
2
git config --global user.name "用户名"
git config --global user.email 邮箱

配置权限：

  1. local（优先级最高）：默认，只影响本地；
  2. global (优先级中等) ：影响当前用户的git仓库；
  3. system (优先级最低) ：印象到全系统的git仓库；

项目权限

Git权限分Maintainer、Developer、Reporter、Guest四种类型

  1. Maintainer可以创建项目、添加tag、保护分支、添加项目成员、编辑项目
  2. Developer可以克隆代码、开发、提交、push
  3. Reporter可以克隆代码，不能提交
  4. Guest可以创建issue、发表评论，不能读写版本库

分支管理

分支说明

Git代码提交流程

  • 在此流程中，每个软件项目存在两个长期的分支：
    • 主分支（master） - 用于对外发布版本，任何时候在这个分支获得的软件都是稳定版本；
    • 测试分支（test）- 用于新功能测试，存放待测试的版本内容。
    • 开发分支（dev）- 用于日常开发，开发环境中，存放的代码与Master分支代码保持一致，方便各个服务进行联调，禁止将测试，开发的代码合并到此分支。
  • 此外，还存在两个种类的短期分支：
    • 功能分支（feature） - 开发某项特定功能，从master分支上面分出来的；开发完成后，再合并到master和dev分支；
    • 补丁分支（hotfix） - 修复已发布软件的bug分支，从master上分支出来；开发完成后，进行测试，再合并到master和dev分支上；

分支命名规范

功能分支

该分支名称应该为迭代功能版本或功能英文简称；

1
2
3
feature/CME-V1.3
或者
feature/pay-order

Bug修复、热修复分支

该分支主要是解决线上Bug的问题，命名尽量描述此次解决的问题，建议使用英文简称

1
hotfix/order-error

流程规范

功能开发git规范

  1. 从master分支切出一个分支，根据功能还是Bug进行分支命名，比如feature/cme-v1.2
  2. 其他开发者拉取代码，开发者在开发完毕后，合并代码到feature分支，并提交代码到远程分支
  3. 自测完毕后，开发组长进行codeReview
  4. 由开发人员将代码合并到test分支，进行提测
  5. 测试过程中，测试人员提交bug，开发人员在feature分支进行bug修复，修复完成后，开发组长进行codeReview，完成后再次提交到test分支，进行提测
  6. 测试通过后，开发人员切换dev分支，将代码合并到dev中
  7. 评审通过后，开发人员将feature代码合并到master中
  8. 线上测试无问题后，开发人员关闭删除feature分支

生产环境 Bug 修复流程

生产环境的 Bug 分两种情况：
紧急 Bug： 严重影响用户使用的为紧急 Bug，需立即进行修复,如关键业务流程存在问题，影响用户正常的业务行为。
非紧急 Bug 或优化： 非关键业务流程问题，仅影响用户使用体验，或出现频率较小等，为非紧急 Bug，可规划到后续版本进行修复。

Bug开发流程：

非紧急 Bug： 修复参考“GIt-代码提交规范”。
紧急 Bug 修复：

  1. 需要从 master 分支切出一个紧急 hotfix修复分支
  2. 开发完成后，开发组长进行codeReview，完成后，合并到test分支进行测试
  3. 测试完成后，hotfix分支内容合并到dev分支。
  4. 代码审核通过后，开发人员合并到master
  5. 构建master代码进行部署

提交日志操作规范

IDEA Git提交描述规范插件

git commit message helper
enter description here

enter description here

Git提交描述格式规范解析

Git提交描述规则可以映射到插件下图部分，Header， Body，Footer
提交信息布局

一个规范的Git提交描述格式如下

1
2
3
4
5
6
7
8
# Header头
<type>(<scope>): <subject>

# Body体
<body>

# Footer体
<footer>

1.Header头

Header头只有一行,包括3个字段: type(必需), scope(可选), subject(必需)

属性 描述
type(必填) commit提交类型
scope(选填) commint提交影响范围
subject(必填) commint提交简短描述
type 提交类型
type说明提交类型： 只允许使用下面属性
属性 描述
feat 新增 feature
fix 修复 bug
docs 仅仅修改了文档，比如 README, CHANGELOG, CONTRIBUTE等等
style 仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
refactor 代码重构，没有加新功能或者修复 bug
perf 优化相关，比如提升性能、体验
test 测试用例，包括单元测试、集成测试等
build 构建项目
ci 对CI配置文件修改
chore 改变构建流程、或者增加依赖库、工具等
revert 回滚到上一个版本
init 初始化项目
scope 此次变更范围

scope说明提交影响范围：一般是修改的什么模块或者是什么功能，如【xx模块】/【xx功能】

subject 简短描述-提交主题

subject 说明提交简短描述： 一般是5-10各自简单描述做的任务，如【xx模块加入消息队列】

2.Body体

body说明提交详细描述：对于功能详细的描述，解释为什么加入这段代码，为什么调整优化等，如因分布式锁问题，导致死锁问题，优化调整xxxx

3.Footer脚

Footer脚包括2个字段: Breaking Changes、Closed Issues

属性 描述
重大变更 中断性不兼容变动(不常用)
关闭问题 关闭Issues问题

4. 重大变更

当前版本与之前版本不兼容，如迭代升级对之前版本不能做到兼容，就需要在Breaking Changes后面描述变动理由和迁移方法之类，此属性不常用

5.关闭问题

当前 commit提交针对某个issue问题或者是禅道bug编号等，如Closes # 234

完成填充示例

完成填充示例 #### 实例Git提交解析 举两个个常用git提交描述案例 ##### 短信模块新功能提交 ![功能开发提交内容填写](https://static.loky.wang/blog/markdown/2024/7/23/1721698678556.png) 模板填写完毕后的内容
用户模块禅道bug1026修复提交

bug修复提交内容模板
填写完毕后内容

参考地址：
敏捷开发GIT分支管理规范 https://zhuanlan.zhihu.com/p/394734031
Git 分支管理及规范 https://blog.csdn.net/stone_tomcate/article/details/127786962
史上最全最好的Git分支使用规范 https://www.ctyun.cn/zhishi/p-346845
Git与团队协作实践技巧：项目经验总结 https://www.php.cn/faq/625579.html
Git - 多人协同开发利器，团队协作流程规范与注意事项 https://www.kancloud.cn/a173512/php_note/1690806