git分支管理和git提交规范

一、git分支管理

最基本的一般情况下的分支管理如下（有些公司会比较复杂，分支管理会根据不同项目而定）：

master分支：生产环境分支，一般用于存放正式环境上的代码，每次发版到正式时才更新，其他时间不允许修改。（每次发版后可以打个tag，标记这次大版本的发布。如果有重大bug修复发的小版本可以打大版本下的小版本tag）

bug分支：bug分支，万一正式环境出现严重bug妨碍使用时需要创建个bug分支进行修改，然后同步到release分支进行测试。测试后再同步到master分支发布，然后还要同时同步到iteration分支、develop分支

release分支：测试环境上的分支，开发完所有功能代码经过开发人员自测后把需要上线的功能代码同步到测试环境上，供测试工程师测试。

iteration分支：本迭代上线分支，开发过程中的需求可能会有一部分是当前迭代要上线的，一部分是下个版本上线的，所以在接到需求时就要区分好，如果是本迭代需求就需要在iteration分支这个分支进行开发，开发完了之后要同步到develop开发分支上。（该分支开发完了自测后就发布到release测试分支）

develop分支：开发分支，永远保持最新所有需求的开发代码，包括上面提到的四个分支修改后的所有代码都要pull拉取同步到该分支。

二、git提交规范

规范些的团队，一般对于 commit 的内容要求职责明确，颗粒度要细，便于后续出现问题排查。

开发过程中每次git提交代码的功能模块和bug修复点尽可能细，避免出现部分代码需要提取而又难找的情况。提交的注释尽可能简明扼要，按规范提交。
规范提交代码能快速提炼、回退、查看提交的代码。

1、提交前缀规范（区分类别）

(1) feat：新增功能或页面；
(2) delete：删除功能或文件；
(3) fix：修复bug、解决冲突（尽量避免）；
(4) modify：修改功能；
(5) docs：修改文档；
(6) refactor：代码重构，未新增任何功能和修复任何bug；
(7) build：改变构建流程，新增依赖库、工具等（例如webpack、gulp、npm修改）；
(8) style：仅仅修改了空格、缩进、注释等，不改变代码逻辑的变动；
(9) perf：改善性能和体现的修改；
(10) chore：变更构建流程或辅助工具，非src和test的修改；
(11) test：测试用例的新增、修改；
(12) ci：自动化流程配置修改；
(13) revert：回滚到上一个版本；

2、提交文字规范

格式：提交前缀：动作行为+问题内容
示例：
（1）feat：新增xx页面
（2）feat：新增xx页面xx功能
（3）fix：修复xx页面xx bug
（4）modify：修改xx页面xx功能
（5）delete：删除xx页面
（6）refactor：重构xx页面xx功能
（7）style：删除多余注释代码/控制台打印代码
（8）refactor：迁移xx文件到xx目录

注意：如果模块很多，那么针对一个模块的提交规范如下
feat(模块名)：新增xxx功能

3、单次提交注意事项

1、提交问题必须为同一类别；
2、提交问题不要超过3个；
3、提交的commit发现不符合规范，git commit --amend -m "新的提交信息"或 git reset --hard HEAD^ 重新提交一次

有兴趣可以了解下这个插件：提交规范插件