git规范例子

发表于 | 分类于

git的一个工作流规范

基本状态示意图

工作流示意图

正常的工作流里面，我们会把分支分为 release，develop 和开发人员的提交分支。

release 分支的含义是相对稳定，发布在正式环境上面的代码。这个分支是一个短命分支，里面的更改和优化不会再回溯到 develop 分支中去。bug 的修复会发布一个小版本；而一个功能发布会重新定义 release 分支，以前的就舍弃掉了。

develop 分支的含义是一个相对不稳定，可能再开发的阶段的代码。这里面的代码一般情况下是下一个阶段会发布的代码，通常会跑在内测环境上面。

提交信息使用中文

团队成员里面大概不会有不认识中文的同学，全体使用中文的话，能够提高可读性。

如果本来英文就不好，然后写出了蹩脚的信息，再让另一个英文不好的同学去阅读，这时候基本很难看明白。

关于使用英文的好处，因为团队里面国外开发人员的情况较少，所以基本不太需要英文来交流；当然，英文还有另外一个好处，那就是在命令行使用的时候，不需要进行输入法切换。

分支命名规则

  • feature/xxx-xxx (命名一个功能分支)
  • issue/xxx-xxx (命名一个 develop 线上的修复)
  • hotfix/xxx-xxx (命名一个 release 线上的修复)
  • refactor/xxx-xxx (命名一个优化分支)

基本开发流程

  1. 从 develop 线上切一个功能分支出来。

  2. 到 gitlab 上面提交 MergeRequest，并且添加 [WIP] 关键字到标题中，标明这处于开发中的状态。

  3. 持续进行开发，并且经常 rebease 到最新的 develop。

  4. 找设计师进行面对面的 UI Review，和一些细节调整。

  5. 审核完毕之后，整理合并成一个符合规范的 Commit。

  6. 到 gitlab 上面修改分支状态，去掉 [WIP] 关键字，并且通知 Reviewer。如果审核通过，那么就合并到主分支，并且删除远程分支。

Commit 模板

1
2
3
4
5
TYPE(功能标题)：功能简述

这是是描述的第一段信息，用举例说明提交一个合法的提交信息是怎么样的。

这是是描述的第二段信息，用来说明这次提交的一些东西。

HOTFIX 修复

定义一个 hotfix 的修复是需要条件的，不是所有的线上问题都应该进行 hotfix。如果把一个BUG的等级分为一般，重要，和紧急三个等级的话，那么只有紧急状态才会进行 hotfix。而其他状态都应该提交一个 issue，随着下次版本升级而修复。而一旦一个 hotfix 提交，并且合并，那么需要即刻上线或者当天上线。

HOTFIX Commit 模板

1
2
3
4
5
6
7
8
9
HOTFIX(影响文件)：功能简述

BUG原因：

这是是描述这次BUG产生的原因，具体可以到谁哪个Commit造成的。

修复方式：

这里是描述这次修复的方式，可能有什么黑科技需要注意的。

ISSUE 修复

一个BUG如果不是用 hotfix 那么就应该用 issue 进行修复。

而一个 issue 修复可能是因为以前的代码造成的，那么括号里面应该写清楚本次修复影响的文件；如果新的功能造成的，那么括号中描述就应该写上与那个功能相关的功能标题。

ISSUE Commit 模板

1
2
3
4
5
6
7
8
9
ISSUE(影响文件/功能标题)：功能简述

BUG原因：

这是是描述这次BUG产生的原因，具体可以到谁哪个Commit造成的。

修复方式：

这里是描述这次修复的方式，可能有什么黑科技需要注意的。

分支线类型列表

FEATURE： 功能开发

ISSUE： BUG 修复

HOTFIX：紧急 BUG 修复

REFACTOR：优化和重构

DOC: 更改文档

CHORE：其它更改， 比如更新工具