当前位置:网站首页>git使用规范

git使用规范

2020-11-10 12:04:49 AlexZ33

代码提交习惯

代码(或其他工作内容)禁止长时间暂存在本地,建议每天(或更短)保存到服务器,以防止电脑故障带来的损失。另外为与团队及时交流,
建议尽早提交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-chglogAngularJS 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

版权声明
本文为[AlexZ33]所创,转载请带上原文链接,感谢
https://segmentfault.com/a/1190000037783650