git commit 检查

[hudeng-go]

git commit 信息中添加issue关联检查，具体规则为commit 信息中需要包含‘Issue: ***'内容，用于关联github的issue或者pms bug单。

[hudeng-go]

该检查启用后，会配合prow 的skip插件通过/skip命令在必要时候跳过检查。

[hudeng-go]

该检查是为了自动生成release-note,我觉得可以参考https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md @zccrs @Zeno-sole @black-desk @BLumia @asterwyx

[black-desk]

显然并不是所有的commit都应该有关联的issue:

以refact类型的提交为例, 研发人员在自发编写代码质量提升的更改的patch时, 几乎没有理由先提一个issue再进行对应的更改.

这是因为哪怕自己先提了一个issue, 也只能将原本需要写在commit message中的所有内容复制一份到这个新提出的issue中.

以及这种类型的更改几乎不可能涉及到需要写在release note中的内容.

[black-desk]

我们并不能认为我们目前所有的项目都已经稳定, 所有的提交都是为了修正某些bug.

对于正在进行特性开发的研发人员来说, 很可能会遇到这样的情况:

1. 在自己的仓库中开了一个分支, 比如 black-desk/feat/some-feature
2. 向该分支上提交feat: A
3. 向该分支上提交feat: B
4. 发现feat: A中新增的代码有bug

此时研发人员有两种解决方案.

1. 编辑feat: A, 然后对feat: B进行rebase.

   但是这种处理方案可能会带来额外的工作量:

   对于正在进行新特性开发的研发人员来说, 我们常常会出现feat: B和feat: A中有对同一个文件的修改的情况.

   这种情况下对feat: A编辑后, rebase feat: B时可能会发生冲突.

2. 提交一个新提交

   当这个pr合并后, 由于这个提交会出现在master上, 又确实修复了之前存在的bug, 所以我们应当使用fix作为commit类型.

   所以最后这个提交我们将其命名为fix: fix bug in A

   这种处理方式下, 我们会产生出一个不应该有关联issue的fix提交. 因为毕竟我们不可能为项目中尚且不存在的bug提一个issue.

我觉得要求研发人员为了维护提交历史的干净而进行巨大的额外工作是非常不可接受的. 毕竟我们人力本来就不够.

综上所述 这种检查不应该成为强制的, 顶多只能是一种建议.

比如写一个bot, 当commit中没有Issue:时, 对第一个更改的文件进行一个评论, 要求研发人员点击解决对话按钮来确定这个提交确实没有相关联的issue.

[black-desk]

无论如何处理这个问题, 有个现状都会继续延续下去, 那就是测试人员总是无法在不熟悉项目结构和技术原理的情况下快速弄明白一个提交到底更改了什么东西.