Git 工做流，看这一篇就够了

时间 2021-08-13

标签前端 webpack git github web npm json 前端框架微信框架栏目 Git 繁體版

原文原文链接

1. Git 提交规范

做为一个开发人员必不可少的工具，代码提交平常一个很是频繁的操做，而对于团队规范建设来讲，Git提交信息的规范是一件颇有必要的工做。前端

1.1 为何要规范提交信息

首先规范提交信息确定是有必要的，简单总结下几点好处：webpack

让项目的维护或使用人员能了解提交了哪些更改
清晰的历史记录，可能某天本身就须要查到呢
规范的提交记录可用于自动生成修改日志(CHANGELOG.MD)
基于提交类型，触发构建和部署流程

1.2 用什么规范？

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

对于提交的备注至少包含四种前缀描述，方便相互了解变更了啥github

<类型>[可选的做用域]: <描述> [可选的正文] [可选的脚注]复制代码

1.3 Commit message 规范落地

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

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>复制代码

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

一、type

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

主要 type前端框架

feat：增长功能
fix：修复 bug

特殊 type微信

docs：文档变更（documentation）
style：格式变更（不影响代码运行的变更）
revert: 执行 git revert 打印的 message
build：构造工具的或者外部依赖的改动，例如 webpack，npm
refactor：重构代码（即不是新增功能，也不是修改 bug 的代码变更）

暂不使用 type框架

merge：解决冲突时合并提交，并未作代码变更
chore：辅助工具的变更, 或者其余变更等
test: 添加测试或者修改现有测试
perf: 提升性能的改动
ci: 与 CI（持续集成服务）有关的改动

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

若是 type 为feat和fix，则该 commit 将确定出如今 Change log 之中。其余状况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

二、scope

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

三、body

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

四、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

一、全局安装 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。

二、项目内安装 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 只能作格式规范，没法触及内容。对于内容质量的把控只能靠咱们本身。

三、添加相应配置

建立 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"}
}复制代码

四、使用

执行 git cz 进入 interactive 模式，根据提示依次填写

1.Select the type of change that you're committing 选择改动类型 (<type>)

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

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

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

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

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

生成的 commit message 格式以下：

<type
  >(<scope>):<subject>  <BLANK LINE><body>  <BLANK LINE> <footer></footer></BLANK></body></BLANK></subject></scope
></type>复制代码

填写完毕后，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上传代码时，须要先将本身的代码同步到本身远程仓库对应的分支中，再切换到要本地的主分支将本身本地开发的分支代码进行合并，若是有冲突先在本地解决，最后再同步到远程的主分支。