前言

没有规矩，不成方圆。遵循一个好的规章制度能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性，不会显得杂乱无章，管理困难。

本文将以idea开发工具为统一使用的基础出发

开发分支管理

分支约定

基于Git分支管理策略Git Flow，结合现有情况进行以下分支约定：

有主分支和辅助分支两类分支，通常主分支也被称为长期分支。

主分支用于组织与软件开发、部署相关的活动；
辅助分支组织为了解决特定的问题而进行的各种活动。

git分支管理

主分支

master分支

命名规则：无固定命名规则
master分支存放的是随时可供在生产环境中部署的稳定版本代码
master分支保存官方发布版本历史，release tag标识不同的发布版本
一个项目只能有一个master分支
仅在发布新的可供部署的代码时才更新master分支上的代码
每次更新master，都需对master添加指定格式的tag，用于发布或回滚
master分支是保护分支，不可直接push到远程仓master分支
- 即：不可以直接在master分支上进行开发
master分支代码只能被release分支或hotfix分支合并

develop分支

命名规则：无固定命名规则
develop 为开发分支，一般包含正在开发的所有新特性
develop分支衍生出各个feature分支
develop分支不建议与主分支直接交互
develop分支是保护分支，不可直接push到远程仓库develop分支
- 即：不可以直接在develop分支上进行开发
一个项目只能有一个develop分支

注意：一般来说，我们会选择将master分支和develop分支作为长期分支，长期分支是不会被删除的，会和你的project项目共存亡。即除非你project不再需要了，否则，这两个分支切出来以后就永远都不允许删除。当然也有一些特例，可以只保留master分支。

为什么develop不建议合并到master分支：

开发分支用于开发新功能，可能同时进行多个功能的开发。将这些功能隔离在开发分支中，可以避免对主分支造成干扰，直到功能完成并通过测试。

通过创建发布分支（Release Branch），可以在不影响开发分支继续开发新功能的情况下，准备和测试即将发布的版本。这样可以确保发布的版本是经过充分准备和测试的。

当然，也是可以从develop分支合并到master，但是一样需要在验证成功后，新增相应的tag标识才能合并过去

辅助分支

辅助分支是用于组织解决特定问题的各种软件活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作、以及对版本代码的测试。这些分支与主分支不同，通常只会在有限的时间范围内存在。这个有限的时间范围比如说一个开发周期，规定在两个礼拜，那么到了第二个礼拜的最后一天开发周期完成，代码合并，该分支就应该被删除掉。

辅助分支包括：

用于开发新功能时所使用的feature分支
用于辅助版本发布的release分支
用于修正生产代码中的缺陷的fix分支
- hotfix分支，用于微调如文字、样式等细小的改动、补丁
- bugfix分支，用于修正生产代码中的缺陷的分支

以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与Git其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。

feature分支

使用规范：

命名规则：feature/* 或者 feature/name/featureName , name-开发者名称，featureName-需求名称
- 如feature/yuks/xxx功能开发
develop分支的功能分支
feature分支使用develop分支作为它们的父类分支
以功能为单位从develop拉一个feature分支
每个feature分支颗粒要尽量小，以利于快速迭代和避免冲突
当其中一个feature分支完成后，它会合并回develop分支，
当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支
feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里
feature分支只与develop分支交互，不能与master分支直接交互

release分支

使用规范：

命名规则：release/，“”以本次发布的版本号为标识
- release/v2024_06_20_a
release分支主要用来为发布新版的测试、修复做准备
当需要为发布新版做准备时，从develop衍生出一个release分支
release分支可以从develop分支上指定commit派生出
release分支测试通过后，合并到master分支并且给master标记一个版本号
release分支一旦建立就将独立，不可再从其他分支pull代码
必须合并回develop分支和master分支

release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。

成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

hotfix分支

使用规范：

命名规则：hotfix/*
- hotfix/xxx文本调整
hotfix分支用来给master已有的生产版本快速微调功能
只能从master分支指定tag版本衍生出来
一旦完成修复bug，必须合并回master分支和develop分支
master被合并后，应该被标记一个新的版本号
hotfix分支一旦建立就将独立，不可再从其他分支pull代码

除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。

当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。

这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。

bugfix分支

使用规范：

命名规则：bugfix/*
- bugfix/xxxbug修复
和hotfix分支类似，不过这个分支类型是用来处理bug 的。

tag的使用

避免在版本回退时不清楚\遗忘以前的版本，仅仅靠开发人员脑力记忆回忆版本。容易出错，故在每一次发布版本代码封板时候新增一个tag标识。

版本号(tag)命名规则，二者选其一
- v${yyyy}_${mm}_${dd}_${letter}，如v2024_06_20_a
  
  其中letter为修订号，为小写字母a-z，若不够再增加一个小写字母a-z如v2024_06_20aa
- 主版本号.次版本号.修订号，如2.1.13。(遵循GitHub语义化版本命名规范)
版本号仅标记于master分支，用于标识某个可发布/回滚的版本代码
对master标记tag意味着该tag能发布到生产环境
对master分支代码的每一次更新(合并)必须标记版本号
仅项目管理员有权限对master进行合并和标记版本号

新增一个tag

tag版本格式
- v ${yyyy}_$ {mm}__ ${dd}$ {letter}，如v2024_06_20a
  
  其中letter为小写字母a-z，若不够再增加一个小写字母a-z如v2024_06_20aa
在idea中新增一个tag
- 选中本次提交的分支->最后一次提交->右键打开菜单->找到New Tag按钮，点击->在弹出的窗口中输输入此次的版本号
- 提交代码的时候勾选push tags这样就会推送到远程仓库

查看tag

idea中的查看
- 点击git窗口右边的🔍，在弹出来的窗口中输入对应版本号回车即可
远程仓库中的查看
- 访问仓库地址->点击code->点击tags->点击输入框->搜索

git提交Commit message格式

每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。

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

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

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

你可以为 git 设置 commit template

修改 ~/.gitconfig, 添加:

[commit]
template = ~/.gitmessage

新建 ~/.gitmessage 内容可以如下:

# head: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: 动宾结构，25字以内，可以中文
#
# body: 36个字每行. 可以中文描述:
# * 为什么这次修改是必须的?
# * 它是怎么解决这个问题的?
# * 有没有其他副作用?
#
# footer:
# - 是否包含相关issue，例如 fix #12341.
# - 是否为BREAKING CHANGE: 对外变更等，都需要在这儿描述，例如
# BREAKING CHANGE: 对外API发生变更
# 以前的API是什么样的，现在API是什么样的

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

（1）type

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

feat：新功能fix：错误修复docs：修改文档style：格式修改（不影响功能，例如空格、分号等格式修正）refactor：代码重构perf：代码优化test：新增测试build：构建依赖更改ci：更改 CI 配置文件或者脚本chore：更改构建流程、或者增加依赖库、工具等revert：代码回退

（2）scope

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

（3）subject

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

尽量简短，但是说明这次提交大致是做了什么如：更新xx功能路由配置

Body

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

1、更新了路由配置2、新建了xx子路由文件3、删除了xxx路由配置

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

使用插件提交

在idea中可以使用插件来更好的规范提交格式
- git-commit-message-helper
- git-commit-message-template

目录CONTENT

记一次git使用规范

前言

开发分支管理

分支约定

主分支

master分支

develop分支

辅助分支

feature分支

release分支

hotfix分支

bugfix分支

tag的使用

新增一个tag

查看tag

git提交Commit message格式

Header

Body

Footer

使用插件提交

评论区