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

荔枝吻2025-07-11 14:36

目录

  • 前言
  • 一、创建用户规范
  • 二、分支开发规范
    • [1. Git Flow](#1. Git Flow)
    • [2. 个人推荐](#2. 个人推荐)
  • 三、提交日志规范
    • [1. Conventional Commits](#1. Conventional Commits)
    • [2. 个人推荐](#2. 个人推荐)
  • 四、实际开发案例
    • [1. 搭建项目](#1. 搭建项目)
    • [2. 安装Git Flow](#2. 安装Git Flow)
    • [3. Git Flow初始化](#3. Git Flow初始化)
    • 4.feature分支
      • [4.1 feature分支1](#4.1 feature分支1)
      • [4.2 feature分支2](#4.2 feature分支2)
      • [4.3 feature分支3](#4.3 feature分支3)
      • [4.4 feature分支2](#4.4 feature分支2)
    • [5. release分支](#5. release分支)
    • [6. hotfix分支](#6. hotfix分支)
  • 参考文献

前言

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. 个人推荐

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

  • feature分支：开发人员姓名缩写-包模块-子模块-功能
  • release分支：版本号-版本代号
  • hotfix分支：年月日-开发人员姓名缩写-issue-序号/bug-错误内容

三、提交日志规范

提交日志规范我们选择行业最为广泛的规范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 提交信息进行结构化的规范。它建议每条提交都遵循如下格式：

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类型也不定局限与推荐的这些，可以根据自己需要自定义一些，下面整理一下个人推荐规范

git 复制代码 
<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地址

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

修改远程仓库名称

cmd 复制代码 
git remote rename 旧远程仓库名称 origin

这样看着好多了

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

2. 安装Git Flow

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

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

3. Git Flow初始化

我用的是之前的一个微服务项目，只有master分支，提交了很多次，也不同担心有什么影响

确保之前的内容已经全部提交并推送到远程了

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

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

bash 复制代码 
git flow init

此时分支如下

把develop分支推送到远程

点击push

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

4.feature分支

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

4.1 feature分支1

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

创建分支

bash 复制代码 
git flow feature start zcy-engine-data

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

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

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

bash 复制代码 
git flow feature finish zcy-engine-data

finish后自动切换到develop分支，推送之前先拉取，防止远程冲突，有冲突在本地解决

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

把develop分支推送到远程

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

4.2 feature分支2

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

后续相同命令就不再截图展示了

  • 创建feature分支
bash 复制代码 
git flow feature start zcy-resources
  • 添加一个规范文件，并提交至本地
  • 同develop分支最开始一样，创建feature远程分支并推送
  • 切换到develop分支
  • 拉取develop分支
  • 合并feature功能分支到当前develop分支
  • 推送develop分支

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

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

bash 复制代码 
git flow feature track zcy-resources

4.3 feature分支3

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

  • 创建feature分支
bash 复制代码 
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分支，假设我们已经开发一段时间，发布第一个小版本上线测试

创建分支

bash 复制代码 
git flow release start v4.2.0-beta.01

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

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

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

bash 复制代码 
git flow release finish v4.2.0-beta.01

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

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

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

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

再把tag推送到远程仓库

bash 复制代码 
git push --tags

变成vv了，哈哈

还差一步，分别把master分支和develop分支推送到远程，这样一个完整的开发流程就结束了

6. hotfix分支

线上出了问题，创建hotfix分支，操作流程和release流程是一样的，

提供两个名称示例

bash 复制代码 
git flow hotfix start 20250707-zcy-issue-128
git flow hotfix start 20250707-zcy-bug-login

参考文献

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~

txt 复制代码 
/*
                   _ooOoo_
                  o8888888o
                  88" . "88
                  (| -_- |)
                  O\  =  /O
               ____/`---'\____
             .'  \\|     |//  `.
            /  \\|||  :  |||//  \
           /  _||||| -:- |||||-  \
           |   | \\\  -  /// |   |
           | \_|  ''\---/''  |   |
           \  .-\__  `-`  ___/-. /
         ___`. .'  /--.--\  `. . __
      ."" '<  `.___\_<|>_/___.'  >'"".
     | | :  `- \`.;`\ _ /`;.`/ - ` : | |
     \  \ `-.   \_ __\ /__ _/   .-` /  /
======`-.____`-.___\_____/___.-`____.-'======
                   `=---='
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            佛祖保佑       永无BUG
*/
相关推荐
云畅新视界6 小时前
从 CODING 停服到极狐 GitLab “接棒”，软件研发工具市场风云再起
人工智能·gitlab
hwj运维之路9 小时前
GitOps实践指南：GitLab CI/CD + ArgoCD 实现 Kubernetes 自动化部署
ci/cd·gitlab·argocd
世事如云有卷舒3 天前
Ubunt20.04搭建GitLab服务器，并借助cpolar实现公网访问
linux·服务器·gitlab
HalukiSan4 天前
如何提交PR
git·gitlab·github
东林牧之4 天前
CICD[软件安装]：docker安装gitlab
docker·容器·gitlab
东林牧之4 天前
CICD[导航]、docker+gitlab+harbor+jenkins从安装到部署
docker·gitlab·jenkins
一世一生命5 天前
Windows下Gitlab多账号（3个及以上）SSH配置
运维·ssh·gitlab
裁二尺秋风6 天前
CI/CD — Pipeline的使用以及Blue Ocean多分支流水线的使用方法
ci/cd·gitlab·jenkins
北海之灵6 天前
docker desktop部署本地gitlab服务
docker·容器·gitlab
热门推荐
01使用Ruby接入实时行情API教程02KGG转MP3工具|非KGM文件|解密音频03Coze扣子平台完整体验和实践（附国内和国际版对比）04深度神经网络训练过程与常见概念05集群聊天服务器---MySQL数据库的建立06扣子（coze）实战|我用扣子搭建了一个自动分析小红薯笔记内容的AI应用|详细步骤拆解07【无标题】08Java学习第十五部分——MyBatis09DeepSeek各版本说明与优缺点分析10LOT: 通过逻辑增强大型语言模型的零样本Chain-of-Thought推理能力