乐趣区

关于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 succeedAll 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 性能开发
fix bug 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 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

退出移动版