NipGeihou's blog NipGeihou's blog
  • Java

    • 开发规范
    • 进阶笔记
    • 微服务
    • 快速开始
    • 设计模式
  • 其他

    • Golang
    • Python
    • Drat
  • Redis
  • MongoDB
  • 数据结构与算法
  • 计算机网络
  • 应用

    • Grafana
    • Prometheus
  • 容器与编排

    • KubeSphere
    • Kubernetes
    • Docker Compose
    • Docker
  • 组网

    • TailScale
    • WireGuard
  • 密码生成器
  • 英文单词生成器
🍳烹饪
🧑‍💻关于
  • 分类
  • 标签
  • 归档

NipGeihou

我见青山多妩媚,料青山见我应如是
  • Java

    • 开发规范
    • 进阶笔记
    • 微服务
    • 快速开始
    • 设计模式
  • 其他

    • Golang
    • Python
    • Drat
  • Redis
  • MongoDB
  • 数据结构与算法
  • 计算机网络
  • 应用

    • Grafana
    • Prometheus
  • 容器与编排

    • KubeSphere
    • Kubernetes
    • Docker Compose
    • Docker
  • 组网

    • TailScale
    • WireGuard
  • 密码生成器
  • 英文单词生成器
🍳烹饪
🧑‍💻关于
  • 分类
  • 标签
  • 归档
  • 设计模式

  • 开发规范

    • 前言
    • Java规范
    • Redis规范
    • MySQL规范
    • Git规范
      • 分支
        • master
        • feature
        • test
        • release
        • hotfix
      • Commit message
        • Header
        • type
        • scope
        • subject
        • Body
        • Footer
      • 参考资料
    • MQ规范
  • 经验分享

  • 记录

  • 快速开始

  • 笔记

  • 面试题

  • 微服务

  • 踩过的坑

  • Java
  • 开发规范
NipGeihou
2023-02-27
目录

Git规范

# 分支

在本规范中,将版本分支分为:

  • master :主分支
  • feature :开发分支
  • test :测试分支
  • release :预发布分支
  • hotfix :热修复分支

# master

  • 主分支,由开发组长负责,此分支代码始终保证可用、可交付、可上线。
  • 禁止在此分支进行任何修改操作,通常由 release 分支合并而来,并打上 tag

# feature

  • 开发分支,由开发人员负责,在确定需求后,由 master 分支拉去,以迭代版本号命名 feature/迭代版本号
  • 功能开发只允许在此分支下进行

# test

  • 测试分支,由测试人员负责,当开发人员认为完成需求代码开发并冒烟通过时,将当前迭代的 feature/迭代版本号 分支合并到 test/迭代版本号 分支,测试人员使用此分支构建测试环境,并开展测试工作。
  • 当功能测试不通过时,开发人员在 feature/迭代版本号 分支修复缺陷,并合并到 test/迭代版本号 分支,再次测试,直至测试通过。

# release

  • 预发布分支,由产品经理负责,当测试人员认为完成功能完整性测试后,将当前迭代的 test/迭代版本号 分支合并到 release/迭代版本号 分支,并由运维部署到 UAT 环境,等待产品经理验收。
  • 当验收不通过时,产品经理向测试人员反馈问题,测试人员再向开发人员反馈问题,再走一遍 feature->test->release
  • 验收通过后,合并到 master 分支,并打上 迭代版本号 标签

# hotfix

  • 热修复分支,由开发人员负责,当线上环境出现 BUG 需紧急修复时,从 master 分支拉去代码到 hotfix/迭代版本号 进行修复。
  • 修复完成后,正常再走一遍 test 、 release 。如时间紧迫,可以由开发组长组织 Code Review 评估直接上线的风险,认为修改后的代码出现问题的风险低,可直接合并到 master 上线。

image-20230227132829735

# Commit message

提示

推荐配合 IDEA 插件 Git Commit Template 使用

每次提交,Commit message 都包括三个部分:Header、Body 、 Footer。

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中,Header 是必需的,Body 和 Footer 可以省略。

不管是哪一个部分,任何一行都不得超过 72 个字符(或 100 个字符)。这是为了避免自动换行影响美观。

# Header

Header 部分只有一行,包括三个字段: type (必需)、 scope (可选)和 subject (必需)。

# type

type 用于说明 commit 的类别,只允许使用下面 11 个标识。


feat: 新功能(feature)

fix: 修补bug

docs: 文档(documentation)修改

style: 不影响代码运行的变动(空格、格式化、换行等)

refactor: 重构(即不是新增功能,也不是修改bug的代码变动);因需求变化,对原有功能进行修改

perf: 改进性能的代码变更

test: 增加测试

build: 影响构建系统或外部依赖关系的更改

chore: 构建过程或辅助工具的变动,其他变更

revert: 还原上一次提交

如果 type 为 feat 和 fix ,则该 commit 将肯定出现在 Change log 之中。其他情况( docs 、 chore 、 style 、 refactor 、 test )由你决定,要不要放入 Change log,建议是不要。

# scope

scope 用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。

# subject

subject 是 commit 目的的简短描述,不超过 50 个字符。

  • 以动词开头,使用第一人称现在时,比如 change ,而不是 changed 或 changes
  • 第一个字母小写
  • 结尾不加句号( . )

# Body

Body 部分是对本次 commit 的详细描述,可以分成多行。下面是一个范例。

More detailed explanatory text, if necessary.  Wrap it to 
about 72 characters or so. 

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indent

有两个注意点:

  1. 使用第一人称现在时,比如使用 change 而不是 changed 或 changes 。

  2. 应该说明代码变动的动机,以及与以前行为的对比。

# Footer

Footer 部分只用于两种情况。

1. 不兼容变动

如果当前代码与上一个版本不兼容,则 Footer 部分以 BREAKING CHANGE 开头,后面是对变动的描述、以及变动理由和迁移方法。

BREAKING CHANGE: isolate scope bindings definition has changed.

    To migrate the code follow the example below:

    Before:

    scope: {
      myAttr: 'attribute',
    }

    After:

    scope: {
      myAttr: '@',
    }

    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

2. 关闭 Issue

如果当前 commit 针对某个 issue,那么可以在 Footer 部分关闭这个 issue 。

Closes #234

也可以一次关闭多个 issue 。

Closes #123, #245, #992

# 参考资料

  • git-flow 的工作流程 | Learn Version Control with Git (opens new window)
  • Git 工作流程 - 阮一峰的网络日志 (opens new window)
  • 你必须知道的 Git 分支开发规范 - 让我留在你身边 (opens new window)
  • Commit message 和 Change log 编写指南 - 阮一峰的网络日志 (opens new window)
上次更新: 2024/03/11, 22:37:05
MySQL规范
MQ规范

← MySQL规范 MQ规范→

最近更新
01
Docker Swarm
04-18
02
安全隧道 - gost
04-17
03
Solana最佳实践
04-16
更多文章>
Theme by Vdoing | Copyright © 2018-2025 NipGeihou | 友情链接
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式