一、git分支管理
最基本的一般情况下的分支管理如下（有些公司会比较复杂，分支管理会根据不同项目而定）：
master分支：生产环境分支，一般用于存放正式环境上的代码，每次发版到正式时才更新，其他时间不允许修改。（每次发版后可以打个tag，标记这次大版本的发布。如果有重大bug修复发的小版本可以打大版本下的小版本tag）
bug-xxx分支：bug分支，万一正式环境出现严重bug妨碍使用时，需要从master拉个bug-xxx分支进行修改，然后同步到test分支进行测试。测试后再同步到master分支发布。
test分支：测试环境上的分支，开发完所有功能代码经过开发人员自测后把需要上线的功能代码同步到测试环境上，供测试工程师测试。
feature/xxxx分支：开发分支，每次接到需求迭代时，都是从master分支从拉拉出新分支，命名为有含义的feature/xxxx分支，即为本次需求迭代的开发分支。本地开发自测完了之后就合并到test分支部署。测试完成后将该开发分支合并到master生产分支部署。
二、git提交规范
规范些的团队，一般对于 commit 的内容要求职责明确，颗粒度要细，便于后续出现问题排查。
开发过程中每次git提交代码的功能模块和bug修复点尽可能细，避免出现部分代码需要提取而又难找的情况。提交的注释尽可能简明扼要，按规范提交。
规范提交代码能快速提炼、回退、查看提交的代码。
1、提交前缀规范（区分类别）
(1) feat：新增功能或页面；
(2) delete：删除功能或文件；
(3) fix： 修复问题/BUG；
(4) mod：不确定分类的修改；
(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^ 重新提交一次
有兴趣可以了解下这个插件：提交规范插件