git使用规范

代码提交习惯

代码(或其他工作内容)禁止长时间暂存在本地，建议每天(或更短)保存到服务器，以防止电脑故障带来的损失。另外为与团队及时交流，
建议尽早提交merge request(未完成可标记为WIP状态)，一般要求不超过1周(时间越短越好)。

fork项目到自己名下，同时配置好这个fork项目的CI(注意，需要配置正确的gitlab runner，可能需要runner所有者授权)
本地添加两个remote: 源项目(origin)和自己名下的fork(${your-remote-name})
```
git remote add ${your-remote-name} git@xyz.com:your-name/project-name.git
```
创建本地开发分支(每个Commit只做一件事情)
```
git checkout -b name_of_the_feature_branch
```
进行代码修改，保证必要的检查和测试在本地通过
完成修改，commit到本地(commit message要符合规范，参考相应内容)
git push commit到自己的fork，并发起merge request
```
git push ${your-remote-name} name_of_the_feature_branch
```
填写merge request信息，并关注对应CI运行结果
推进reviewer进行code review并根据review意见修改代码
如果经过review产生有多个commits，建议通过git rebase -i进行squash后提交，保证commit log简单明且符合规范
最终由reviewer合并代码

其他注意事项

一个规范化的commit message，有以下作用：

好的例子:

坏的例子:

附加类别标签前缀(可选，根据项目而定，例如项目需要进行正规的Release管理)，格式参考git-chglog或AngularJS Git Commit Message Conventions

例如：

项目版本号命名规则遵循语义化版本SemVer规范:

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改，
次版本号：当你做了向下兼容的功能性新增，
修订号：当你做了向下兼容的bugfix

类型	命名规则	创建自	说明
master分支	master	-	主开发分支
feature分支	feature功能点名称	master	用于复杂长周期独立feature的开发，不利于敏捷开发，一般不使用
release分支	r+版本号前两位(如r1.0)	master	用于保证release质量，更新代码的code review
release tag	v+版本号(如v2.0.3)	release分支	发行tag版本
release hotfix	只存在于本地	release tag	release bug修复，修复完后打新的tag，PATCH号+1(如v2.0.3 -> v2.0.4)