git-flow.md

Teambition 工作流规范（暂行）

基本状态示意图

正常的工作流里面，我们会把分支分为 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 模板

TYPE(功能标题)：功能简述

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

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

HOTFIX 修复

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

HOTFIX Commit 模板

HOTFIX(影响文件)：功能简述

BUG原因：

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

修复方式：

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

ISSUE 修复

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

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

ISSUE Commit 模板

ISSUE(影响文件/功能标题)：功能简述

BUG原因：

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

修复方式：

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

分支线类型列表

FEATURE： 功能开发

ISSUE： BUG 修复

HOTFIX：紧急 BUG 修复

REFACTOR：优化和重构

DOC: 更改文档

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

一些题外的话

有时候我会觉得，这样写信息非常得浪费时间，不过呢，写下来总是好的，为以后可能发生的问题提供很多可靠的依据。