你必须知道的Git分支开发规范

1 minute read

分支管理

分支命名

master 分支

master 分支为主分支，用于部署生产环境，需要确保master分支的稳定性。
此分支属于只读分支，只能从 release 分支合并过来，任何时候都不能在此分支修改代码。
所有向master分支的推送，都要打上tag标签记录，方便追溯。
此分支只能前进，不能有回退操作。

hotfix/* 分支

生产环境 bug 修复分支，基于 master 分支检出。
属于临时分支，当生产环境出现 bug ，管理员基于 tag 创建 hotfix/<修改者> 分支、 release/<版本号> 分支，由开发人员在hotfix分支修复bug，修复完成后，并且在开发集成环境自测通过、单元测试通过、Sona扫描通过后，再向 release 分支提交 pull request 申请。bug修复完成上线之后可删除此分支。

release/* 分支

release 分支为预上线分支，基于 develop 或 master 分支检出。用于准备发布新阶段版本或者修复线上bug版本。
此分支用于上线前bug测试，文档生成和其他面向发布任务。
此分支属于只读分支，只能由 master 分支或者 develop 分支检出，或者从 bugfix 分支、hotfix 分支合并过来，任何时候都不能在此分支修改代码。
此分支属于临时分支，在发布提测阶段，会以 release 分支代码为基准提测。当 release 分支测试验证通过后，最终会先被合并到 master 分支（发布新版本或者修复线上bug，要打tag标签），再被合并到 develop 分支（使其与 master 分支保持一致），最后删除此分支。
命名：release/<版本号>（例：release/1.0.0）

bugfix/* 分支

预上线 bug 修复分支，基于 release 分支检出。
此分支用于上线前bug修复。
此分支属于临时分支，当提测阶段中存在 bug 需要修复，由开发人员基于 release 分支创建 bugfix/<修改者> 分支，然后在 bugfix/<修改者> 分支进行修复 bug 。 bug 修复完成后，并且在开发集成环境自测通过、单元测试通过、Sona扫描通过后，再向 release 分支提交 pull request 申请。bug修复完成 release 分支测试通过之后可删除此分支。

develop 分支

develop 为开发环境主干分支，基于 master 分支检出。
此分支为只读分支，只能从master、release、feature分支合并过来，任何时候都不能在此分支修改代码。
此分支只能由开发人员提交 pull request（需要 code review），或者由管理员 merge release 分支。
在一个 release 分支没有创建出来时，develop 分支不能合并不包含 release 功能范围的 feature 分支。develop 分支在特殊情况下可以回退版本。

feature/* 分支

feature 分支为功能开发分支，由开发人员基于 develop 分支创建 feature/<功能模块> 分支。
此分支用于新功能开发，一个 feature 分支最大粒度只能到模块。
此分支为临时分支，最终会被合并到 develop 分支（新增功能），或者删除（放弃功能）。
此分支通常仅存在于开发人员本地存储库中，而不存在与远程origin。
一个新功能开发完成后，且在开发集成环境自测通过、单元测试通过、Sona扫描通过后，才能向 develop 分支提交 pull request （需要 code review）。

关于gitflow

gitflow 是一个标准分支规范和pr流程，但是在微服务的发展过程中，协同编码的场景已经很少了，所以如果代码只有个人维护不需要严格按照 gitflow，大体流程按照如上规则即可。但是协同编码需要严格遵守gitflow，提升协同编码的效率。

avatar

git版本号

git采用的是三位不版本号：主版本号.次版本号.修订号

主版本号：做了一些不兼容的API修改，可以理解为一个大的产品更新。
次版本号：新增了一些功能，可以理解为合并了一个feature。
修订号：修复了一些bug，可以理解为合并了一个hotfix。

commit message规范

书写良好的commit message能大大提高代码维护的效率。但是在日常开发中由于缺少对于commit message的约束，导致填写内容随意、质量参差不齐，可读性低亦难以维护。在项目中引入commit message规范已是迫在眉睫。

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

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]

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。

使用

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

Select the type of change that you're committing 选择改动类型 (<type>)
   
What is the scope of this change (e.g. component or file name)? 填写改动范围 (<scope>)
   
Write a short, imperative tense description of the change: 写一个精简的描述 (<subject>)
   
Provide a longer description of the change: (press enter to skip) 对于改动写一段长描述 (<body>)
   
Are there any breaking changes? (y/n) 是破坏性修改吗？默认n (<footer>)
   
Does this change affect any openreve issues? (y/n) 改动修复了哪个问题？默认n (<footer>)

任何git commit指令的option都能用在 git cz指令上, 例如git cz -a

示例

相应的git log：

Twitter Facebook LinkedIn

Ricardo