前言
工作区(Working Directory)
暂存区(Stage)
版本库(Repository)
远程仓库(Remote)
1. Git 分支规范
1.1 分支类型
分支类型基于Git Flow规范,并做了简化。
功能分支(feature)
紫色
发布分支(release)
黑色和红色
修复分支(hotfix)
灰色
主分支(master)
绿色
1.2 分支命名
类型 | 规则 | 备注 |
---|---|---|
功能分支 | feature-* | 以功能或上线日期为准 |
发布分支 | develop | dev环境发布分支 |
发布分支 | test/sit | 测试环境发布分支 |
发布分支 | release* | 预发布和生产发布分支, 默认release,多版本并行可release1, release2 |
修复分支 | hotfix-* | 已修复问题命名 |
主分支 | master | 保护分支,一般发布完生产需要合并到master |
1.3 分支合并
该图的原型为git flow, 原作者为Vincent Driessen
- 公共发版分支,是供给多版本有交叉提测时段时,针对某一环境发版专用的环境发版分支。
- 公共发版分支,必须是单向合并,严禁反向污染。 (gitlab线上合并,有冲突时禁用)
- release生产/预发布发版分支open in new window,由业务线组长或该版本负责人,统一集中合并。
- 公共发版分支维护统筹,由各业务线组长负责;
- 跨业务线开发,需要发布环境时,需主动联系该业务线负责人,说明版本计划、时间、公共包版本等,沟通清楚无异议后方可使用
- 严控版本Tagopen in new window,每次发版后,需业务新建tag入口组长或功能主开发进行操作,格式如下: 生产版本: Tag-YYYYMMDD版 (日期为发版日期) 修复版本: Fix-YYYYMMDD版 (日期为修复日期)
2. Git 提交规范
本节由alan提供。
commit message format(信息域) commit message 一般分为三个部分 Header,Body 和 Footer
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
2.1 HEAD
type
用于说明commit
的类型,允许以下标识:
类型 | 描述 |
---|---|
feat | 新增功能 |
fix | 修复 bug |
docs | 文档变更 |
style | 不影响代码运行的变动如:样式调整 |
refactor | 重构(既不是新增加的 feature,也不是修复 bug) |
pref | 性能优化 |
test | 增加测试如:测试代码 |
chore | 构建过程或者辅助功能的变动 |
revert | 版本回退 |
build | 打包 |
2.2 BODY
本次
commit
的内容描述
2.3 FOOTER
本次
commit
存在不兼容变动或者关闭的 issue
2.4 注意事项
1:每个提交都必须使用类型字段前缀,它由一个名词构成,诸如 feat
或 fix
, 其后接可选的范围字段,可选的 !,以及必要的冒号(英文半角)和空格。
2:当一个提交为应用或类库实现了新功能时,必须使用 feat
类型。
3:当一个提交为应用修复了 bug
时,必须使用 fix
类型。
4:范围字段可以跟随在类型字段后面。范围必须是一个描述某部分代码的名词,并用圆括号包围, 例如: fix(parser): 描述字段必须直接跟在 <类型>(范围) 前缀的冒号和空格之后。 描述指的是对代码变更的简短总结,例如: fix(doc): update ref doc
。
5:在简短描述之后,可以编写较长的提交正文,为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
6:提交的正文内容自由编写,并可以使用空行分隔不同段落。
7:在正文结束的一个空行之后,可以编写一行或多行脚注。每行脚注都必须包含 一个令牌(token),后面紧跟 : 或 # 作为分隔符。
8:脚注的令牌必须使用 - 作为连字符,比如 Acked-by (这样有助于 区分脚注和多行正文)。有一种例外情况就是 BREAKING CHANGE,它可以被认为是一个令牌。
9:脚注的值可以包含空格和换行,值的解析过程必须直到下一个脚注的令牌/分隔符出现为止。
10:破坏性变更必须在提交信息中标记出来,要么在 <类型>(范围) 前缀中标记,要么作为脚注的一项。
11:包含在脚注中时,破坏性变更必须包含大写的文本 BREAKING CHANGE,后面紧跟着冒号、空格,然后是描述,例如: BREAKING CHANGE: environment variables now take precedence over > config files
。
12:包含在 <类型>(范围) 前缀时,破坏性变更必须通过把 ! 直接放在 : 前面标记出来。 如果使用了 !,那么脚注中可以不写 BREAKING CHANGE:
, 同时提交信息的描述中应该用来描述破坏性变更。
13:在提交说明中,可以使用 feat
和 fix
之外的类型,比如:docs: updated ref docs
。
14:工具的实现必须不区分大小写地解析构成约定式提交的信息单元,只有 BREAKING CHANGE
必须是大写的。 BREAKING-CHANGE
作为脚注的令牌时必须是 BREAKING CHANGE
的同义词。 :::
2.5 具体使用
站点已集成
标签:教程,git,版本,--,Git,提交,commit,分支 From: https://www.cnblogs.com/miangao/p/17621391.htmlcommitizen
遵循谷歌conventionalcommits
约定式提交规范,进行了汉化方便辨识同时集成了commitlint
和lintstaged
规则格式校验; 提交类型以及内容体参照