信息 按顺序打印commit_Git 工作流，看这一篇就够了

1. Git 提交规范作为一个开发人员必不可少的工具，代码提交日常一个非常频繁的操作，而对于团队规范建设来说，Git提交信息的规范是一件很有必要的工作。

1.1 为什么要规范提交信息

首先规范提交信息肯定是有必要的，简单总结下几点好处：让项目的维护或使用人员能了解提交了哪些更改

清晰的历史记录，可能某天自己就需要查到呢

规范的提交记录可用于自动生成修改日志(CHANGELOG.MD)

基于提交类型，触发构建和部署流程

1.2 用什么规范？

现在市面上比较流行的方案是约定式提交规范(Conventional Commits)，它受到了 Angular 提交准则的启发，并在很大程度上以其为依据。约定式提交规范是一种基于提交消息的轻量级约定。它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易。这个约定与 SemVer 相吻合，在提交信息中描述新特性、bug 修复和破坏性变更。它的 message 格式如下:

对于提交的备注至少包含四种前缀描述，方便相互了解变动了啥[可选的作用域]:  [可选的正文] [可选的脚注]复制代码

1.3 Commit message 规范落地

目前，社区有多种 Commit message 的写法规范。参考Angular 规范是目前使用最广的写法，比较合理和系统化，并且有配套的工具。前端框架Angular.js采用的就是该规范。如下图：

下面是一个规范信息的结构(): 

// 空一行

// 空一行

复制代码

每个 Git 的 Commit Messages 由以下三部分组成， **header(标题) ** , 可选的  ** body(正文) ** ，可选的  ** footer(页脚)，break changes(删减) **  其中header是必填项。`

1、type

type 为必填项，用于指定 commit 的类型，约定了 feat、fix 两个主要 type，以及 docs、style、build、refactor、revert 五个特殊 type，其余 type 暂不使用。

主要 typefeat：增加功能

fix： 修复 bug

特殊 typedocs：文档变动(documentation)

style： 格式变动(不影响代码运行的变动)

revert: 执行 git revert 打印的 message

build：构造工具的或者外部依赖的改动，例如 webpack，npm

refactor：重构代码(即不是新增功能，也不是修改 bug 的代码变动)

暂不使用 typemerge：解决冲突时合并提交，并未做代码变动

chore：辅助工具的变动, 或者其他变动等

test: 添加测试或者修改现有测试

perf: 提高性能的改动

ci: 与 CI(持续集成服务)有关的改动

当一次改动包括主要 type 与特殊 type 时，统一采用主要 type。

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

2、scope

scope 也为必填项，简单说明，不超过50个字, 中英文均可，若为英文须首字母大写，用于描述改动的范围，格式为项目名/模块名，例如：opinions/topic。如果一次 commit 修改多个模块，建议拆分成多次 commit，以便更好追踪和维护。

3、body

body 填写详细描述，主要描述改动之前的情况及修改动机，对于小的修改不作要求，但是重大需求、更新等必须添加 body 来作说明。

4、footer

可选。主要用于备注相关 bug 的 id，如用 gitlab 须备注 issue 链接 Example Commit Message

5 、break changes

break changes 指明是否产生了破坏性修改，涉及 break changes 的改动必须指明该项，类似版本升级、接口参数减少、接口删除、迁移等。

示例feat(订单流程): 开发支付页

feat(订单流程): 联调支付功能复制代码每次提交都应该是原子性的，要么是修复bug，要么是新功能，要么是文档修改等等， 绝对不允许多个type类型提交混合一起，不然难以 code review。

更详细的说明请看约定式提交规范

1.4 Quick Start如何约束规范，安装 commitlint 和 commitizen 规范和编写符合规范的 commit message

1、全局安装 commitizen & cz-conventional-changelog

commitizen 是一个撰写合格 commit message 的工具，用于代替 git commit 指令，而 cz-conventional-changelog 适配器提供 conventional-changelog 标准(约定式提交标准)。基于不同需求，也可以使用不同适配器。npm install -g commitizen cz-conventional-changelogecho '{ "path": "cz-conventional-changelog" }' > ~/.czrc复制代码

安装完毕后，可直接使用 git cz 来取代 git commit。

全局模式下，需要 ~/.czrc 配置文件, 为 commitizen 指定 Adapter。

2、项目内安装 commitlint & husky

commitlint  负责用于对 commit message 进行格式校验，husky 负责提供更易用的 git hook。# Use npmnpm i -D husky @commitlint/config-conventional @commitlint/cli# Use yarnyarn add husky @commitlint/config-conventional @commitlint/cli -D复制代码

commitlint 只能做格式规范，无法触及内容。对于内容质量的把控只能靠我们自己。

3、添加相应配置

创建 commitlint.config.js# In the same path as package.jsonecho 'module.exports = {extends: ["@commitlint/config-conventional"]};' > ./commitlint.config.js复制代码

引入 husky# package.json

{

...,"husky": {"hooks": {"commit-msg": "commitlint -e $GIT_PARAMS"}

}复制代码

4、使用

执行 git cz 进入 interactive 模式，根据提示依次填写1.Select the type of change that you're committing 选择改动类型 ()

2.What is the scope of this change (e.g. component or file name)? 填写改动范围 ()

3.Write a short, imperative tense description of the change: 写一个精简的描述 ()

4.Provide a longer description of the change: (press enter to skip) 对于改动写一段长描述 (

)

5.Are there any breaking changes? (y/n) 是破坏性修改吗？默认n ()

6.Does this change affect any openreve issues? (y/n) 改动修复了哪个问题？默认n ()复制代码

生成的 commit message 格式如下：

>():     

>

复制代码

填写完毕后，husky 会调用 commitlint 对 message 进行格式校验，默认规定 type 及 subject 为必填项。

任何 git commit 指令的 option 都能用在 git cz 指令上, 例如 git cz -a

2. Git 分支管理

Git分支管理及命名规范

2.1 分支分类

Git主分支(保留分支)：master 、release

Git开发分支(合并至master分支)：dev、dev/[function-username]

Git辅助分支(功能/辅助分支)：feature/[function]、hotfix/、release/

2.2 分支简介

2.2.1 主分支master：对应线上(正式环境)的代码，一旦版本上线由测试人员发送合并matser邮件，开发人员将对应上线tag版本合并至master分支。

release：同 master 分支，预发环境通过之后，上线之前，合并 release 分支。

2.2.2 dev、dev/[function-username] 开发分支dev：日常功能迭代开发使用的为 dev 分支，最初是从 master 拉出，后面所有的功能开发都 merge 回此分支协同开发。

dev/[function-username]：开发者自己的功能分支，根据功能模块-企业微信名称来命名，完成后 merge 回 feature/[function] 分支，并可删除此分支。

2.2.3 feature/[function] 等辅助分支从 master 拉取，用于新需求(版本)开发feature/[function]：功能分支，多人合作开发基于feature分支开发，完成后 merge 回dev分支，并可删除此分支。

hotfix/*：修复分支，线上发布后发现线上 bug 后需要从 master 分支拉出来做 bug 修复，*号为版本号+期次号，完成后 merge 回 master 及 dev 分支，并可删除此分支

release/：预发布分支(非必选)，从 master 拉取，用于确保当前版本是基于线上最新版本迭代，可处理与线上代码存在的冲突。任务辅助分支在测试环境通过之后，上预发环境之前，务必拉取一个 release/ 分支。号为对应的 dev/  或 hotfix/* 的*

2.3 分支命名

2.3.1 需求(版本)开发

从 master 拉取 dev 分支

分支命名规则 ：类型 - 版本号dev-v2.0.1

release-v2.0.1复制代码

Tag命名规则： 类型 - 版本号 - 期次号dev-v2.0.1-102401

release-v2.0.1-102401复制代码

2.3.2 线上问题处理

从 master 拉取 hotfix 分支

分支命名规则：类型 - hotfix英文简称

Tag命名规则： 类型 - hotfix英文简称 - 期次号

分支：hotfix-dateError

release-dateError复制代码

Tag:hotfix-dateError-102401

release-dateError-102401复制代码

3. 代码管理

管理仓库的方式，这边走最普通的 merge 方式： 首先会在gitLab上创建一个仓库，为当前项目中每位开发人员取一个对应的分支，让其在对应的分支开发。 然后clone这个仓库。 当队员需要向gitLab上传代码时，需要先将自己的代码同步到自己远程仓库对应的分支中，再切换到要本地的主分支将自己本地开发的分支代码进行合并，如果有冲突先在本地解决， 最后再同步到远程的主分支。