最近一周的工作重心就是在梳理团队规范，在写的过程也查缺补漏了不少知识，剔除掉关于公司场景的部分就有了这一系列的文章，预计写四部分：

Git 规范

Git 作为现在最流行的分布式管理工具，基本上是每个团队的必备，下面就从分支和提交这两部分展开

什么是分支

分支就是把你的工作从开发主线上分离开来，以免影响开发主线，假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了 50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

分支如何命名

分支按照类型可以分为以下几种

分支名称	命名	说明
主分支	master	主分支，所有提供给用户使用的正式版本，都在这个主分支上发布
开发主分支	develop	开发分支，永远是功能最新最全的分支
功能分支	feature-*	新功能分支，某个功能点正在开发阶段
发布版本	release-*	发布定期要上线的功能
修复发布版本分支	bugfix-release-*	修复测试 bug
紧急修复分支	bugfix-master-*	紧急修复线上代码的 bug

开发流程示例

下面就以一个产品从最初到发布上线为例子，讲解 git 流程

初始化

第一步，初始仓库的信息，同时创建develop分支

开发新功能

开发人员在develop分支开发新的功能，包括:新特性与 Bug 修复

如果并行开发多个需求，可以创建 feature 分支，命名规则为feature-分支创建日期-新特性关键字，例如:feature-20190919-i18n

开发完成之后将 feature 分支合并到 develop 分支，最后删除 feature 分支

什么时候使用 feature

开发一个独立的新特性(完成时，需合并到 develop 分支)

技术研究与尝试(若失败，可随时删除 feature 分支)

提前实现下一个版本需要开发的特性(可不在本次迭代中发布)

准备发布版本

如果 develop 分支上的功开发完毕

建 release 分支(发布分支)命名规则:release-分支创建日期-待发布版本号，例如：release-20190919-v1.0.0
对 release 分支的版本号进行修改（之后提交一次）
通知测试人员测试

修复问题

开发人员在 release 修复问题，此时禁止开发新功能，只对 bug 进行修复

最终发布

经过测试没有发现问题，或者问题已经全部修复，这个时候

将 release 分支同时合并到 master 分支与 develop 分支
- 通知测试，进行主分支测试
- 如果没问题，进行下一步，如果有问题回到 release
删除 release 分支
构建应用到服务器

commit 规范

目前开源社区主要应用是规范是Angular Git Commit Guidelines

它由下面几部分组成:

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

type

本次 commit 的类型，诸如 bugfix、docs、style 等

完整的类型如下：

名称	描述
feat	添加新特性
fix	修复 bug
docs	仅仅修改了文档
style	仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor	代码重构，没有加新功能或者修复 bug
perf	增加代码进行性能测试
test	增加测试用例
chore	改变构建流程、或者增加依赖库、工具等

scope

本次 commit 波及的范围

subject

简明扼要的阐述下本次 commit 的主旨

有几点需要注意：

首字母不要大写
结尾无需添加标点

body

主体内容，我们需要把本次 commit 详细的描述一下，比如此次变更的动机等，不能超出 72 个字符

为什么需要

它可能是用来修复一个 bug，增加一个 feature，提升性能、可靠性、稳定性等等

它如何解决这个问题? 具体描述解决问题的步骤

是否存在副作用、风险?

footer

描述下与之关联的 issue 或 break change，在公司项目中基本忽略即可

参考文章

Git 分支管理规范

团队规范系列之git规范