关于git:git使用规范

代码提交习惯

代码 (或其余工作内容) 禁止长时间暂存在本地 ，倡议每天(或更短) 保留到服务器，以避免电脑故障带来的损失。另外为与团队及时交换，
倡议尽早提交 merge request(未实现可标记为 WIP 状态)，个别要求不超过 1 周(工夫越短越好)。

根本开发流程

1. fork 我的项目到本人名下，同时配置好这个 fork 我的项目的 CI(留神，须要配置正确的 gitlab runner，可能须要 runner 所有者受权)

2. 本地增加两个 remote: 源我的项目 (origin) 和本人名下的 fork(${your-remote-name})

   git remote add ${your-remote-name} git@xyz.com:your-name/project-name.git

3. 创立本地开发分支(每个 Commit 只做一件事件)

   git checkout -b name_of_the_feature_branch

4. 进行代码批改，保障必要的检查和测试在本地通过
5. 实现批改，commit 到本地(commit message 要符合规范，参考相应内容)

6. git push commit 到本人的 fork，并发动 merge request

   git push ${your-remote-name} name_of_the_feature_branch

7. 填写 merge request 信息，并关注对应 CI 运行后果
8. 推动 reviewer 进行 code review 并依据 review 意见批改代码
9. 如果通过 review 产生有多个 commits，倡议通过 git rebase - i 进行 squash 后提交，保障 commit log 简略明且符合规范
10. 最终由 reviewer 合并代码

其余注意事项

1. 合并抵触，个别应该应用 rebase 而非 merge
2. gitlab 我的项目倡议设置成Fast-forward merge
3. gitlab 我的项目倡议设置成 Pipelines must succeed 和All discussions must be resolved
4. 一个 merge request，如果其他人 review 过，除非永恒敞开，否则不应该敞开从新发新的 merge request，这样会失落 review

Commit message 标准

作用

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

1. 让其余合作者能清晰精确的揣测出这个 commit 的内容
2. 能便捷甚至自动化的生成好看的 Release Notes 或 CHANGELOG

标准细则

1. 应用英文(业务相干我的项目除外)
2. 大写字母结尾(非凡状况除外)，简练但具体的形容

好的例子:

• Support LeakyReLU conversion from TensorFlow
• Add Gather and Scatter ops for DenseTensor

坏的例子:

• Fixing broken links
• Some fix
• Fix compatibility bug

1. 附加类别标签前缀(可选，依据我的项目而定，例如我的项目须要进行正规的 Release 治理)，格局参考 git-chglog 或 AngularJS Git Commit Message Conventions

例如：

• feat: Add Gather and Scatter ops for DenseTensor

版本号标准

我的项目版本号命名规定遵循语义化版本 SemVer 标准:

版本格局：主版本号. 次版本号. 订正号，版本号递增规定如下：

主版本号：当你做了不兼容的 API 批改，次版本号：当你做了向下兼容的功能性新增，订正号：当你做了向下兼容的 bugfix

分支、tag 治理

参考资料: A successful Git branching model