1. git commit规范
Git是目前最流行的版本管理系统之一，让团队协作开发更加高效方便。在团队协作开发过程中，commit message规范对团队管理非常重要。因此，规范化的提交信息对于代码的阅读和维护来说是非常必要的。
1.1 COMMIT MESSAGE格式
格式要求：类型(type)[范围(scope)]: 描述(subject)
其中：
type
feat：新功能（feature）
fix：修复问题（bug）
docs：修改文档（documentation）
style：修改代码样式不影响代码含义的变化（white-space, formatting, missing semi-colons, etc）
refactor：代码重构（既不新增功能，也不是修改bug的代码变动）
test：增加测试或修改现有测试（adding missing tests, refactoring tests）
chore：改变构建流程、或者增加依赖库、工具等
scope
涉及修改的模块
subject
用一句话清楚描述这个修改做了什么
示例1：
feat(component): 新增xxx组件
示例2：
fix(page): 修复xxx页面的xxx问题
1.2 COMMIT MESSAGE内容
1.第一行为提交信息，短小精悍，限制在50个字符以内
2.第二行为空白行
3.第三行之后是详细的注释信息，可以分成多行，每行的字符数不要超过72个字符
示例：
feat(component): 新增xxx组件
这是详细注释信息，可以分成多行，每行的字符数不要超过72个字符。
- xxx问题1
- xxx问题2
2. git branch规范
在多人协作开发中，合理的分支管理能够很好的促进开发进度的顺利进行。因此，规范代码分支管理对团队开发进度很有好处。
2.1 分支命名规范
1.主分支
master：主分支，主要用于发布。
develop：开发分支，主要用于开发。
2.特性分支
feat/xxxx：新功能开发。
fix/xxxx：修复bug。
refactor/xxxx：重构代码。
style/xxxx：修改代码格式。
示例：
// 新功能开发
git checkout -b feat/login
// 修复xxx问题
git checkout -b fix/xxx
// 代码格式修改
git checkout -b style/xxx
2.2 特性分支操作
1.新功能开发分支创建并提交
// 创建新功能开发分支
git checkout -b feat/login
// 开发新功能
// 将代码提交到本地仓库
git add .
git commit -m "feat(login): 新增登录功能"
// 将代码推送到远程新功能开发分支
git push origin feat/login
2.新功能开发分支合并到主分支
// 切换到开发分支
git checkout develop
// 拉取远程新功能开发分支的代码并合并到develop分支
git merge origin/feat/login
// 将develop的代码推送到远程develop分支
git push origin develop
// 删除本地和远程新功能开发分支
git branch -d feat/login
git push origin :feat/login
3. git tag规范
使用Git时，我们往往会为项目打上标签，以便于快速定位历史版本。那如何给标签上合理的版本号呢？
3.1 语义化版本号规范
版本号格式：主版本号.次版本号.修订版本号
1.主版本号：当你做了不兼容的API修改；
2.次版本号：当你做了向下兼容的功能性新增；
3.修订版本号：当你做了向下兼容的问题修正。
示例：
v1.0.0：第一次正式发布
v1.1.0：在第一次发布的基础上新增了一些功能
v1.1.1：在第一次发布的基础上修复了一些bug
3.2 tag创建规范
1.新特性版本发布
// 新特性版本发布tag
git tag -a v1.2.0 -m "New feature release"
// 将tag推送到远程仓库
git push origin v1.2.0
2.发布修复版本
// 发布标签
git tag -a v1.2.1 -m "Bug fixes release"
// 推送tag
git push origin v1.2.1
只有在正式发布版本时，才要创建标签。在开发、测试中使用的版本不需要打标签，可以使用分支管理。
4. 总结
对于团队协作开发，git的规范化使用，对于代码管理来说非常重要。对于团队内部统一使用的git规范，可以约定一个git规范文档，每个人在团队开发前仔细阅读一遍，以确保规范的使用。