分支命名：
为了区分不同的开发任务，我们通常会为相关的改动创建新的分支。 以下是一些常见的分支命名约定：
-
功能分支：以
feature/为前缀，后接描述性名称。示例：
feature/add-login -
修复bug分支：以
fix/为前缀，后接JIRA ticket或者描述性名称。示例：
fix/login-error -
优化分支：以
refactor/为前缀，后接描述性名称。示例：
refactor/speed-up-homepage -
重构分支：以
rework/为前缀，后接描述性名称。示例：
rework/header-styles -
测试分支：以
test/为前缀，后接描述性名称。示例：
test/e2e-login-flow -
发布分支：以
release/为前缀，后接版本号。示例：
release/1.0.0 -
热修复分支：以
hotfix/为前缀，后接描述性名称。示例：
hotfix/crash-on-start -
文档分支：以
docs/为前缀，后接描述性名称。示例：
docs/update-readme -
配置分支：以
config/为前缀，后接描述性名称。示例：
config/add-sonar-quality-gate -
主题分支：以
theme/为前缀，后接描述性名称。示例：
theme/dark-mode
在实际开发中，选择合适的分支名可以提高团队协作效率，使得项目的维护和更新变得更加清晰和有序。
命名格式: 类别 + / + 日期/迭代版本号/功能名称
例： feat/2.1.1、fix/20201214
一些比较复杂的系统，需要子系统迭代的，就会用到功能名称，例：
feat/user_manage_1.1.1、fix/user_manage_20201214
提交信息
常见的分类有下面几种：
build：修改项目的的构建系统（xcodebuild、webpack、glup等）的提交ci：修改项目的持续集成流程（Kenkins、Travis等）的提交chore：构建过程或辅助工具的变化docs：文档提交（documents）feat：新增功能（feature）fix：修复 bugpref：性能、体验相关的提交refactor：代码重构revert：回滚某个更早的提交release：发布新版本style：不影响程序逻辑的代码修改、主要是样式方面的优化、修改test：测试相关的开发improvement：在现有功能上优化、改进
提交格式: 分类：具体描述信息（建议中文）
