git使用规范

码农天地 - 2020-11-13 12:28:20

---

代码提交习惯

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

其他注意事项

合并冲突，一般应该使用rebase而非mergegitlab项目建议设置成Fast-forward mergegitlab项目建议设置成Pipelines must succeed和All discussions must be resolved一个merge request，如果其他人review过，除非永久关闭，否则不应该关闭重新发新的merge request，这样会丢失reviewCommit message规范作用

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

让其他合作者能清晰准确的推测出这个commit的内容能便捷甚至自动化的生成美观的Release Notes或CHANGELOG规范细则使用英文(业务相关项目除外)大写字母开头(特殊情况除外)，简练但具体的描述

好的例子:

Support LeakyReLU conversion from TensorFlowAdd Gather and Scatter ops for DenseTensor

坏的例子:

Fixing broken linksSome fixFix compatibility bug附加类别标签前缀(可选，根据项目而定，例如项目需要进行正规的Release管理)，格式参考git-chglog或AngularJS Git Commit Message Conventions类型说明feat功能开发fixbug fixperf性能优化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 reviewrelease 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

Tags 标签