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

james
861 阅读7分钟

1. Git 提交规范

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

1.1 为什么要规范提交信息

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

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

1.2 用什么规范？

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

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

<类型>[可选的作用域]: <描述> [可选的正文] [可选的脚注]

1.3 Commit message 规范落地

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

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

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

1、type

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

主要 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，建议是不要。

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-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

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

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

2、项目内安装 commitlint & husky

commitlint 负责用于对 commit message 进行格式校验，husky 负责提供更易用的 git hook。

# Use npm
npm i -D husky @commitlint/config-conventional @commitlint/cli

# Use yarn
yarn add husky @commitlint/config-conventional @commitlint/cli -D

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

3、添加相应配置

创建 commitlint.config.js

# In the same path as package.json

echo '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 选择改动类型 (<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上传代码时，需要先将自己的代码同步到自己远程仓库对应的分支中，再切换到要本地的主分支将自己本地开发的分支代码进行合并，如果有冲突先在本地解决， 最后再同步到远程的主分支。 git-flow.png

avatar
文章
阅读
粉丝