git 工作流

分支规范

• 主分支（保护分支）：master

正式环境分支，所有新版本都应由此处 checkout 出去。 这个分支用于合并其他的功能分支并发布到线上，应该相对独立，不能在该分支直接修改。

• 主分支（保护分支）：develop

测试环境分支，揉杂正在测试的各个分支以及大部分的测试用代码，严格上禁止将此分支合并到功能分支或从他 checkout 新分支。

• 辅助分支

1. feature 功能分支，version由产品以语义化版本的规范确定。
2. hotfix 线上热修复分支
3. release 预发布分支

辅助分支用于临时的开发需要，在功能上线且测试通过的情况下应该及时删除。

创建新功能分支或热修复分支

// 所有新功能都应该从master分支切出去
git checkout master

git checkout -b feature/v3.0.5

合并功能分支到测试环境

git checkout develop

git merge feature/v..

删除分支

git branch -D feature/v..

对应提交内容摘取

git cherry-pick [commit-id]

git 提交命名规范

遵循三要素原则，即

• 类型（模块 || 总结）type

• 内容 content

• 备注 remarks

对应公式为：

<type>(<content>): <remarks>

其中类型和内容必填，备注选填。

1.类型

规范的主要类型如下：

• feat：新功能或功能变更相关

• fix：修复 bug 相关

• docs：改动了文档，注释相关

• style：修改了页面样式或代码格式化相关，如删除空格、改变缩进、单双引号切换、增删分号等，并不会影响代码逻辑

• refactor：重构代码，代码结构的调整相关（仅改变写法，理论上不改变主流程）

• perf：性能改动，性能、页面等优化相关

• test：增加或更改测试用例，单元测试相关

• build： 影响编译的更改相关，比如打包路径更改、npm 过程更改等

• chore：其它改动相关，比如文件的删除、构建流程修改、依赖库工具更新增加等

其中项目中用得较多的是 feat、fix、docs、style。

2.内容

简短概括本次提交文件包含的内容，可以是修复了什么缺陷、完成了某一个模块的功能，建议在一行内描述完毕。

3.备注

该模块为选填，可以附带上对提交信息有帮助的内容，如修复缺陷对应的 bugId、线上热修复时间等。

一些优秀的提交信息（摘取自 antd）

git commit -m "feat(shadow): adjust less variable of shadow according to the document"

git commit -m "fix(Form): scrollToError abnormal sequence of dynamic form"