如何解决Git Commit Message Linting作为网关，而不是在已推送之后
我想在整个组织中验证特定的提交消息结构，我希望无法合并/推送到主/主要提交，除非消息符合非常特定的格式。
通过简单的正则表达式可以覆盖提交消息，期望的格式如下：
packaging将提交添加到主/主中的方式有几种：
- 在主机上本地提交，推送到远程。
- 在分支上本地提交，在本地合并到主节点，推送到远程。
- 本地提交分支，打开拉取请求（以github为例）从github UI合并PR 。
我可以使用 git-commit 钩子轻松覆盖＃1的情况，要覆盖2和3，我可以使用CI钩子，但这会在事实发生之后例如现在修复提交格式为时已晚。
对于2，我可能还可以添加一个 pre-push hook ，但是对于3，鉴于该操作发生在服务器端，我似乎找不到一个简单的解决方案提交已经在master / main分支上后，不执行linting过程。
解决方法
对GitHub上的存储库执行此操作的正确方法是为此使用CI作业，如有必要，可以使用机器人进行合并。您可以有效地对存储库施加任何控制的唯一两个地方是pre-receive钩子和CI系统，并且GitHub不允许您自定义存储库中的配置之外的pre-receive钩子。 / p>
在用户端使用挂钩很容易被绕开，并且不是有效的控件。因此，如果您关心提交消息，那么唯一可以控制它的地方就是使用CI。 Git FAQ explains why this is the case。
您应该使用GitHub设置保护您的主分支，并设置选项“合并之前要求状态检查通过。”这意味着人们要么需要将所做的更改放入PR中，然后在合并之前通过您的CI检查，要么将他们想要推送的提交推送到主分支到临时分支，然后在CI检查之后快速转发主分支通过。
如果您希望合并消息还包含特定的字符串，那么您需要让机器人执行所有PR合并并负责合并，因为您无法在发生合并之前通过CI检查来检查合并消息
没有任何其他有效的解决方案可以解决这个问题：替代方案可以被轻易绕开，或者是无效的。要求人们以某种方式格式化提交消息，即使是在进行中的PR上工作，也并非没有特别大的负担。我曾在这是政策的工作岗位上工作，这不是问题。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
