Git 分支与GitFlow 流程的规范.md 4.1 KB
title: Git 分支管理流程规范 keywords: teedoc, gitflow, git, 静态博客 desc: Git 分支管理流程规范 author: devin date: 2023-05-20
tags: blog, blog, teedoc
Git 分支与GitFlow 流程的规范
1、 GitFlow 原理介绍
Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。
工作流中涉及到的角色介绍：
- 功能开发者：模块中功能的开发人员；
- 开发管理员：由项目模块开发的小组长（team leader）担当；
- 测试管理员：由测试团队指定人员担当；
- 发布管理员：由生产环境发布团队指定人员担当；
分支说明
2、 Git 分支
2.1 Master/Develop 分支
所有在 Master 分支上的 Commit 应该打上 Tag，一般情况下 Master 不存在 Commit，Develop 分支基于 Master 分支创建。
2.2 Feature 分支
Feature 分支做完后，必须合并回 Develop 分支, 合并完分支后一般会删点这个 Feature 分支， 毕竟保留下来意义也不大。
2.3 Release 分支
Release 分支基于 Develop 分支创建，打完 Release 分支之后，我们可以在这个 Release 分支 上测试，修改 Bug 等。同时，其它开发人员可以基于 Develop 分支新建 Feature (记住：一旦打了 Release 分支之后不要从 Develop 分支上合并新的改动到 Release 分支)发布 Release 分支时，合并 Release 到 Master 和 Develop， 同时在 Master 分支上打个 Tag 记住 Release 版本号，然后可以删除 Release 分支了。
2.4 Hotfix 分支
hotfix 分支基于 Master 分支创建，开发完后需要合并回 Master 和 Develop 分支，同时在 Master 上打一个 tag。
3、 Git 分支的合并和Commit
3.1 基本要求
- 所有commit必须有注释，内容必须按照注释格式严格执行！
- 合理控制提交内容的颗粒度，一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。
- 正确为每个项目设置Git提交用到的user.name和user.email信息，以公司邮箱为准，不可随意设置以影响无法正确识别。 查看当前项目配置信息的命令：
git config -l
3.2 版本
- 版本号(tag)命名规则：
主版本号.次版本号.修订号，如2.1.13。(遵循GitHub语义化版本命名规范) - 版本号仅标记于master分支，用于标识某个可发布/回滚的版本代码
- 对master标记tag意味着该tag能发布到生产环境
- 对master分支代码的每一次更新(合并)必须标记版本号
- 仅项目管理员有权限对master进行合并和标记版本号
3.3 Commit 规范日志
提交信息一定要认真填写！
- 建议参考规范：(scope)：
- 比如：fix(首页模块)：修复弹窗 JS Bug。
- type 表示 动作类型，可分为：
- fix：修复 xxx Bug
- feat：新增 xxx 功能
- test：调试 xxx 功能
- style：变更 xxx 代码格式或注释
- docs：变更 xxx 文档
- refactor：重构 xxx 功能或方法
- scope 表示 影响范围，可分为：模块、类库、方法等。