代码提交习惯

代码(或其余工作内容)禁止长时间暂存在本地，倡议每天(或更短)保留到服务器，以避免电脑故障带来的损失。另外为与团队及时交换，
倡议尽早提交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性能开发
fixbug fix
perf性能优化
docs增加文档
style代码格调批改
refactor性能不变的重构
test补充测试
chore维护性工作

例如：

  • feat: Add Gather and Scatter ops for DenseTensor

版本号标准

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

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

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

分支、tag治理

类型命名规定创立自阐明
master分支master-主开发分支
feature分支feature性能点名称master用于简单长周期独立feature的开发，不利于麻利开发，个别不应用
release分支r+版本号前两位(如r1.0)master用于保障release品质，更新代码的code review
release tagv+版本号(如v2.0.3)release分支发行tag版本
release hotfix只存在于本地release tagrelease bug修复，修复完后打新的tag，PATCH号+1(如v2.0.3 -> v2.0.4)

参考资料: A successful Git branching model