Git版本管理
分支
- master：主分支(保护分支)，不能直接在 master 上进行修改代码和提交；
- develop：测试分支，所以开发完成需要提交测试的功能合并到该分支；
- feature：开发分支，根据不同需求创建独立的功能分支，开发完成后合并到 develop 分支；
- fix：bug 修复分支，对已发布的版本进行漏洞修复；
Tag
采用三段式，v版本.里程碑.序号，如 v1.2.1
- 架构升级或架构重大调整，修改第 1 位
- 新功能上线或者模块大的调整，修改第 2 位
- bug 修复上线，修改第 3 位
Git提交信息
提交信息格式采用目前主流的 Angular 规范，这是目前使用最广的写法，比较合理和系统化，并且有配套的工具。
提交信息格式说明
提交信息一般包括三部分：Header、Body 和 Footer。
<type>(<scope>): <subject>
<空行>
<body>
<空行>
<footer>其中，Header 是必需的，Body 和 Footer 可以省略。
Header
Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）。
<type>(<scope>):<subject>
- type：用于说明提交类别，规定为以下几种 ：
- feat：新增功能；
- fix：修复bug；
- docs：修改文档；
- refactor：代码重构，未新增任何功能和修复任何bug；
- build：改变构建流程，新增依赖库、工具等（例如webpack修改）；
- style：仅仅修改了空格、缩进等，不改变代码逻辑；
- perf：改善性能和体现的修改；
- chore：非src和test的修改；
- test：测试用例的修改；
- ci：自动化流程配置修改；
- tmp： 临时提交（可用于非 master 分支）
- revert：回滚到上一个版本；
- scope：用于说明 commit 影响的范围，比如数据层、控制层、视图层、包名、文件名等等。
- subject：是 commit 目的的简短描述，不超过50个字符，结尾不加句号。
对本次 commit 的详细描述，应该说明代码变动的动机，以及与以前行为的对比，可分多行。
Footer 有两种情况：
- 是否有重大的改变(是否有突破性的变化)：框架式改变，或者跟上一版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。
- 这一变化是否影响到任何尚未解决的问题(关闭 issue)：可以填写 fix #1 等于关闭问题1 或者 使用 Closes #1，关闭多个 issue 使用 fix #1,#2,#3 逗号分割，关闭了三个issue。
2346
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
