如何避免开发人员在没有提及Github上提交消息的情况下提交

在我工作的公司，我们定义了一个小的开发过程来满足我们的需求。在提交之前，我们应该在提交评论中提及该问题。这将在我们的CI上触发一些内部钩子，并将在我们的测试环境中提供该问题进行测试

我们的项目目前托管在GitHub上，我们也有一个配置良好的Jenkins CI服务器。问题是：“我们如何才能迫使开发人员在提交前提及问题？”。我想知道Git钩子是否可以帮助我们，但看起来钩子在开发人员机器上是本地的

---

有人知道什么可以帮助我们吗？

我认为你的方法需要调整。Git被设计成在您经常提交时最好。例如，我经常以单个提交的形式提交对多个文件的小更改。以后的更改可以被压扁、挑选、重定基址或重新排列。但是强迫每一次提交都关注一个问题只会导致提交次数减少，这对开发人员不利

此外，代码需要备份，如果您将代码推到远程服务器，这是一种将代码放在两个位置的简单方法，并且在开发过程中与其他人“共享”。只要它是一个独立的分支，这就是解决代码中问题的一种好方法

---

据我所知，您的问题在于粒度和github存储库作为“主”存储库的概念。如果您只想-deploy-for-general测试处理特定问题的提交块，那么就有一个git-repo，它在-every-commit-to-master上提取一个中心github-repo副本，但只有在提交注释中提到问题时才触发集成/部署到测试过程。通过这种方式，开发人员可以根据需要推送中间提交，也可以根据需要推送开发分支，而不必有任何特殊的含义，而且只有问题修复提交块才会导致部署/集成。

我们的团队最近遇到了同样的问题，即没有参考票证号的毫无价值的提交消息

我们是如何处理这件事的

沟通，表示这不是正确的方法，也是无效的

使用GitHub pull请求，我们拒绝将不符合我们规范（现在包含提交消息格式）的代码合并到主线中，开发人员将重新设置其分支的基础，以修改提交消息以符合标准

---

我们考虑强制开发人员安装使用regex解析消息的本地钩子，但决定不采用这种方法，因为有时开发人员希望快速提交（而不是隐藏），他们可以稍后重新设置基址，而不必在本地遵循该格式

如果您试图强制提交消息采用特定格式（即始终以特定格式存在问题），那么预接收钩子可能是您唯一的方法。

钩子如何成为本地问题？告诉开发人员安装它们，对不安装的人大喊大叫，直到他们安装。git是否有预提交钩子？如果是这样的话，这应该是相当直接的，以防止签入没有正确的评论。服务器端“预接收”钩子。@克里斯服务器钩子在这里不是一个真正的选项，因为服务器是由github运行的。提供的唯一钩子是通知存储库更改的钩子，没有什么可以拒绝推送不符合要求的提交。我一直认为“每个提交都必须与修复问题关联”是一个可怕的反模式。这就像坚持开发人员的每一次击键都必须可以追溯到一个需求。Tchalvak，非常感谢您的回答。我同意你对承诺减少的担忧，这在过去几个月可能是一个巨大的问题。但是，最近，我们所有的开发人员成员都接受了培训，并采用了“许多提交”的概念，即他们的文化。今天，我们在一个有4个开发人员的团队中，每天大约有180个提交。本周我注意到大约有20次提交在提交评论中没有问题。这避免了在测试版Q/A之后提交到生产环境的一些承诺。下周将有更多的开发者与我们合作，其中一个在我的国家之外。。我怎么能同意他们总是写这篇文章？克里斯托弗，我理解你的观点。。。我们这里没有很多规则，这个“提交问题”和行为驱动的单元测试是这里唯一的规则。至少，开发人员可以在同一问题上进行多个提交。通过将问题连接到提交，我们可以自动将刚刚批准（测试）的问题移动到生产环境中，并允许我们的continuos交付几乎没有重复工作（几个月前我们曾经有很多重复工作）。我不同意多个观点。虽然提交通常很好，但这并不意味着所有提交都需要推送到共享开发分支。推到一个只用于某个特性的分支或远程分支是完全可以的，但是当您将其合并到主开发分支中时，我相信每个特性应该只有一个提交。如果一个功能在历史上分散了20次提交，就不可能恢复。我也不同意将源代码管理作为备份的一种形式。如果必须推送备份，则推送到一个分支，然后在合并之前挤压。