【发布时间】:2021-03-28 20:23:08
【问题描述】:
如果任何提交包含无效消息,我希望 Github 拒绝所有 Git 更改。每条消息都应遵循以下模式
<type> <issue>: <message>
例如
feat #28: Support multiple file upload
在哪里
-
type应该是预定义列表中的现有类型(feat、fix、ci、...) -
issue应该是现有的问题编号(如果甚至可以检查) -
message的长度应介于 1 到 100 个字符之间
我知道本地运行的 Git 挂钩。所以我可以防止配置预提交挂钩的无效提交。但是可以简单地在本地删除该钩子,强制提交并将该代码推送到 Github。当然,我已经配置了受保护的分支,所以“攻击者”只能破坏他自己的分支。但是我仍然需要自己检查拉取请求中的消息。
最好将 Github 配置为通过智能错误消息拒绝每个更改
-
abc #28: message goes here被消息拒绝
因为 'abc' 不是有效类型而被拒绝
-
feat #99999: message goes here被消息拒绝
因为问题不存在而被拒绝
-
feat #28:被消息拒绝
因为消息为空而被拒绝
如果可能的话,有人知道如何配置这样的“安全”功能吗?
想象一下很多人都在做这个项目,每个人都应该遵守规则。提交消息应该有一个共同的风格,以便阅读提交历史。我知道只有维护者才能直接推送到 repo,但可能会“忘记”规则并创建包含违反规则的提交的推送。
【问题讨论】:
-
FWIW 这类规则非常烦人。例如,想想当标题为
Merge remote-tracking branch 'origin/master' into my-feature-branch的提交被拒绝时会发生什么。想要实施这样的规则的原因是什么? (请编辑问题以解决)。 -
您需要 Enterprise 在 GitHub 上运行预接收挂钩:stackoverflow.com/q/10864903/3001761
-
@AD7six 这是个好问题……我没想到。我更新了我的问题
-
我建议放弃原始问题的细节,而是使用squash and merge PR commits 加上 PR 标题/描述约定(例如:PR 必须引用要批准和合并的问题)。主人的历史将坚持问题中概述的意图,而没有预接收方法的(显着,IMO)缺点。