关于git: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)

参考资料: A successful Git branching model

代码提交习惯