Git 教程

标签：教程 git 版本 -- Git 提交 commit 分支

前言

工作区（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的内容描述

本次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 具体使用

站点已集成commitizen遵循谷歌 conventionalcommits约定式提交规范，进行了汉化方便辨识同时集成了commitlint和 lintstaged规则格式校验；提交类型以及内容体参照
标签：教程,git,版本,--,Git,提交,commit,分支
From： https://www.cnblogs.com/miangao/p/17621391.html

前言