【保姆级喂饭教程】GitLab创建用户规范，分支开发规范，提交日志规范

前言

Git 是一个分布式版本控制系统，用于管理和跟踪代码或文件的变更。是软件团队进行代码开发管理的必要工具。
GitHub、GitLab 是一个基于 Web 的 Git 仓库，由于 GitHub 的私有仓库是收费的，而 GitLab 是开源的，所以小型团队一般选择自己部署一个 GitLab。
为了更好的团队使用，这里梳理下创建用户规范，分支开发规范，提交日志规范，仅适用于小型团队。

一、创建用户规范

Name：姓名大写
UserName：姓名全拼音小写
Email：个人提供或公司统一邮箱

---

二、分支开发规范

分支开发我们选择Git Flow规范

1. Git Flow

Git Flow 是 Vincent Driessen 在 2010 年提出的一套 Git 分支管理模型，它通过 主分支（master）、开发分支（develop） 以及若干辅助分支（feature、release、hotfix 等）来规范团队协作与发布流程。
原文：A successful Git branching model
GitHub：https://github.com/nvie/gitflow
教程1：Git之GitFlow工作流 | Gitflow Workflow（万字整理，已是最详）
教程2：git flow
安装：【保姆级喂饭教程】Windows下安装Git Flow

总结一下核心部分：

分支类型	来源	目的	合并目标
master	—	保存可发布的历史版本；每次发布都会在此打 tag	—
develop	master	日常开发集成；累积新的功能和改动	—
feature/XXX	develop	开发新功能或业务需求；独立进行直至功能完成	develop
release/XXX	develop	预发布准备：修复 bug、更新版本号、编写文档；上线前的最后调试	master、develop
hotfix/XXX	master	紧急修复生产环境问题；快速修补并生成新版本	master、develop

2. 个人推荐

个人推荐分支命名规范，功能看需求可选

开发人员姓名缩写-包模块-子模块-功能

三、提交日志规范

提交日志规范我们选择行业最为广泛的规范Conventional Commits

1. Conventional Commits

官网：英文 | 中文
GitHub：https://github.com/conventional-commits/conventionalcommits.org
教程1：Git 提交注释规范（Conventional Commits）详解与实践推荐
教程2：拯救你的Commit Log：Conventional Commits实践指南
插件：【保姆级喂饭教程】idea中安装Conventional Commit插件

Conventional Commits 是一种对 Git 提交信息进行结构化的规范。它建议每条提交都遵循如下格式：

<type>[optional scope]: <description>[optional body][optional footer(s)]

• type：本次提交的类型（如 feat、fix、docs 等）
• scope（可选）：本次更改影响的范围或模块
• description：简要描述更改内容
• body（可选）：详细描述
• footer（可选）：破环性更新或关联 issue

type类型	描述
fix	类型 为 fix 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 PATCH 相对应）。
feat	类型 为 feat 的提交表示在代码库中新增了一个功能（这和语义化版本中的 MINOR 相对应）。
build	用于修改项目构建系统，例如修改依赖库、外部接口或者升级 Node 版本等。
chore	用于对非业务性代码进行修改，例如修改构建流程或者工具配置等。
ci	用于修改持续集成流程，例如修改 Travis、Jenkins 等工作流配置。
docs	用于修改文档，例如修改 README 文件、API 文档等。
style	用于修改代码的样式，例如调整缩进、空格、空行等。
refactor	用于重构代码，例如修改代码结构、变量名、函数名等但不修改功能逻辑。
perf	用于优化性能，例如提升代码的性能、减少内存占用等。
test	用于修改测试用例，例如添加、删除、修改代码的测试用例等。

2. 个人推荐

一般除了发布版本不用写详细描述，一行即可，type类型也不定局限与推荐的这些，可以根据自己需要自定义一些，下面整理一下个人推荐规范

<type>(包模块/子模块): <description>

type类型	描述
build	构建项目，创建模块，修改全局配置，修改pom文件等
feat	新增加一个功能，从0到1的时候使用
dev	开发一个功能，从1到100的时候使用
opt	优化功能代码，优化算法，优化性能，从100到120的时候使用
test	提交测试相关代码
docs	用于修改文档，添加资料
fix	用于在代码库中修复了一个 bug

build整体项目的时候用root
备用可选：add，revise，refine

四、实际开发案例

这里通过一个实际的微服务项目开发流程来演示分支开发规范和提交日志规范

1. 搭建项目

在gitlab中创建项目作为远程仓库

创建本地项目

创建本地git仓库

连接远程仓库，在idea中第一次提交后push会有定义远程仓库

name要填origin，url填gitlab中的clone地址

这里我之前填了项目名，看起来不好看，下面修改一下

修改远程仓库名称

git remote rename 旧远程仓库名称 origin

这样看着好多了

或者也可以重新clone一遍项目，远程仓库名称会变成默认的origin

2. 安装Git Flow

一键安装方式，下载压缩包，解压到git的安装目录的bin目录下
Git Flow一键安装补丁

完整教程请参考下面链接：
【保姆级喂饭教程】Windows下安装Git Flow

3. Git Flow初始化

我用的是之前的一个微服务项目，只有master分支，提交了很多次，也不同担心有什么影响
确保之前的内容已经全部提交并推送到远程了

直接在idea中的终端进行操作，先试下git flow，没什么问题

初始化，一路回车，版本前缀输入v

git flow init

此时分支如下

把develop分支推送到远程

点击push


此时gitlab上有两个内容完全一样的分支

4.feature分支

此处连续演示三个功能分支，第一个创建一个新的模块给同事用，第二个创建一个功能分支公共使用，第三个创建一个功能分自己开发用

4.1 feature分支1

这个分支创建一个模块给同事用，是一个简单的本地功能分支，不需要推送远程

创建分支

git flow feature start zcy-engine-data

日志说明是基于develop分支创建了功能分支，使用git flow的好处就是无论当前在哪个分支，执行前都会自动基于develop/master分支创建功能分支


创建模块后提交，注意提交日志格式

由于只创建一些文件，所以也不用推送到gitlab，等合并到develop分支再推送，直接结束当前分支

git flow feature finish zcy-engine-data

推送之前先拉取，防止远程冲突，有冲突在本地解决

关于两种分支合并方式，这里简单推荐两个教程，正常用merge就行
你合并代码用 merge 还是用 rebase ?
合并分支代码的2种选择？

把develop分支推送到远程


这样一个简单功能就完成了，之后同事拉取后再次创建自己的功能分支即可

4.2 feature分支2

这个分支创建一个文档分支，是一个长期的功能分支，需要推送到远程
后续相同命令就不再截图展示了

• 创建feature分支

git flow feature start zcy-resources

• 添加一个规范文件，并提交至本地
• 同develop分支最开始一样，创建feature远程分支并推送
• 切换到develop分支
  
• 拉取develop分支
• 合并feature功能分支到当前develop分支
  
• 推送develop分支

如果你有专门的审计团队，也可以全程在gitlab上申请分支合并，经过审查后再执行合并，本地develop分支只做拉取。
gitlab合并分支代码

如果另一个同事也需要开发这个分支，可以在本地创建一个同样名称的功能分支再连接远程，也可以直接从远程下载

git flow feature track zcy-resources

4.3 feature分支3

这个分支创建一个功能分支，是一个长期的功能分支，需要推送到远程

• 创建feature分支

git flow feature start zcy-engine-tokenizer

• 对于确定长期的分支，可以先创建远程仓库，之后更新分支就可以提交加推送了

• 修改功能代码，提交同时推送到远程仓库
  
  
  

• feature分支需要每日推送工作进度，可以在功能初步完成时合并到develop分支，切换到develop分支

• 拉取develop分支

• 合并feature功能分支到当前develop分支

• 推送develop分支

4.4 feature分支2

假设功能分支3和功能分支2有关联，那么在继续开发功能分支2之前需要同步develop分支的内容

• 切换到feature功能分支2
• 把develop分支合并到当前功能分支
  
• 继续开发改动一些文件
• 提交并推送到远程feature分支
• 切换到develop分支
• 拉取develop分支
• 合并feature功能分支到当前develop分支
• 推送develop分支

这样，就实现了简单的功能开发和团队协作

5. release分支

最后再演示一下release分支，假设我们已经开发一段时间，发布第一个小版本上线测试

创建分支

git flow release start v4.2.0-beta.01

在feature分支下使用命令创建release分支，验证下git flow的自动切换功能

可以看到是从develop分支建立的

我们不做任何改动，直接完成

git flow release finish v4.2.0-beta.01

分析下日志，首先切换到master分支，把release分支递归合并

然后进入tag信息编辑，按i进入编辑，输入发布测试，按esc，输入:wq，回车

之后切换到develop分支，拉取，递归合并，删除

git flow最后也会给你输出一个操作汇总，忘记之前填了版本前缀v了，之后release分支的名称直接写版本号就好

再把tag推送到远程仓库

git push --tags   

变成vv了，哈哈

还差一步，分别把master分支和develop分支推送到远程，这样一个完整的开发流程就结束了
线上出了问题，创建hotfix分支，操作流程和release流程是一样的

---

参考文献

A successful Git branching model
https://github.com/nvie/gitflow
Git之GitFlow工作流 | Gitflow Workflow（万字整理，已是最详）
git flow
【保姆级喂饭教程】Windows下安装Git Flow
Conventional Commits 英文官网
Conventional Commits 中文官网
https://github.com/conventional-commits/conventionalcommits.org
Git 提交注释规范（Conventional Commits）详解与实践推荐
拯救你的Commit Log：Conventional Commits实践指南
【保姆级喂饭教程】idea中安装Conventional Commit插件
你合并代码用 merge 还是用 rebase ?
合并分支代码的2种选择？

---

喜欢的点个关注吧><！祝你永无bug~

/*_ooOoo_o8888888o88" . "88(| -_- |)O\  =  /O____/`---'\____.'  \\|     |//  `./  \\|||  :  |||//  \/  _||||| -:- |||||-  \|   | \\\  -  /// |   || \_|  ''\---/''  |   |\  .-\__  `-`  ___/-. /___`. .'  /--.--\  `. . __."" '<  `.___\_<|>_/___.'  >'"".| | :  `- \`.;`\ _ /`;.`/ - ` : | |\  \ `-.   \_ __\ /__ _/   .-` /  /
======`-.____`-.___\_____/___.-`____.-'======`=---='
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^佛祖保佑       永无BUG
*/