自从从 SVN 切换到 Git 以来，我们失去了通过 subversion 服务器上的 pre-commit 挂钩来强制执行我们的编码标准的能力。
使用 Git，您只能在客户端上拥有预提交挂钩，而无法以任何方式强制执行。更糟糕的是，我们的开发人员使用所有三个主要操作系统，因此适用于 Linux 或 OS X 的预提交挂钩不会自动适用于 Windows。
解决方法是在服务器上实现一个 pre-receive 挂钩，但解决方案并不像看起来那么简单：
想象一下开发人员进行了 20 次提交并想要推送它们。我知道的所有预提交和预接收挂钩（1、1） com/kore/php-commit-hooks" rel="nofollow noreferrer">2) 仅检查单个提交，这最终会失败并阻止推送。现在，开发人员修复了问题并进行了另一次提交，并尝试再次推送。由于钩子检查单个提交，因此它会再次失败。
因此，我们需要一个 pre-receive 钩子，它生成将要推送的所有提交中所有已更改文件的列表，并仅在当前状态下运行 phpcs。
这样的钩子脚本已经存在吗？在哪里？
编辑：似乎有一个脚本可以创建该文件列表 - 不幸的是在Python中，但这是可以移植的。我仍然对 PHPCS 的预制解决方案感兴趣:)
Since switching from SVN to Git, we lost the ability to enforce our coding standards through a pre-commit hook on the subversion server.
With Git, you only have pre-commit hooks on the client which cannot be enforced in any way. What makes it worse is that we have developers working with all three main operating systems, thus a pre-commit hook that works on Linux or OS X does not automatically work on Windows.
The way to go is implementing a pre-receive hook on the server, but the solution is not as easy as it seems:
Imagine the developer did 20 commits and wants to push them. All pre-commit and pre-receive hooks I know of (1, 2) just check the single commits, which will ultimately fail and prevent the push. Now the developer fixes the issues and does another commit, and tries to push again. Since the hooks check the single commits, it will fail again.
So we need a pre-receive hook that generates a list of all changed files in all commits that are going to be pushed and runs phpcs on the current state only.
Does such a hook script exist already? Where?
Edit: There seems to be a script that creates that list of files - unfortunately in Python, but that can be ported. I'm still interested in pre-made solutions with PHPCS :)
发布评论
评论（10）
我们使用 git 包装器（为了我们的目的用更合理的东西替换 git-submodules），它具有自动从魔术目录自动设置预提交挂钩的副作用。由于这是在商业环境中，因此没有抱怨（并且无论如何都有一种方法可以将其关闭）。
We use a git wrapper (to replace git-submodules with something more sane for our purposes) and it has the side-effect of automatically setting up pre-commit hooks automatically from a magic directory. Since this is in a business environment, there are no complains (and there is a way to turn that off anyway).
我也尝试过这个。我目前手头没有代码，但我使用了其中一个钩子（不是预接收，我认为这是更新的钩子）来临时检查新的引用。您可以通过检出树来加快速度，只需更新该树并进行浅克隆。
这允许访问整个源代码树，您不仅可以在推送更改的文件上运行 CS，还可以运行单元测试或冒烟测试。
我也同意其他一些评论，即这些测试应该保持在最低限度，因为没有什么比被提交钩子阻止更烦人的了。任何进一步的检查都应该在您的 CI 服务器或部署系统中进行。
I have experimented with this too. I don't have the code at hand at the moment, but I used one of the hooks (not pre-receive, I think it was the update one) to do a temporary checkout of the new ref. You can speed this up by having a checked out tree which you just have to update and by just doing shallow clones.
This allows access to the whole source tree and you can not only run CS on the files changed with the push, but also run the unit or smoke tests.
I also agree with some of the other comments that these tests should be kept to a minimum, because nothing is more annoying than being blocked by commit hooks. Any further checks should be happening in your CI server or deployment system.
我们现在使用预提交挂钩来检查代码和提交消息。
开发人员可以使用
-n跳过它们，但他们很少这样做，而且我们总是有另一个开发人员进行 QA，这样事情就会引起注意。该钩子很重要，因为它会注意到文件何时损坏，因此损坏的 PHP 或 JS 根本不会被提交。
在 https://github.com/netresearch/git-client-hooks
我们使用中央服务器进行开发，并且我们的 git 挂钩会自动安装，因为我们提供了一个中央 git 存储库模板，当您
git clone或git init时，该模板会自动使用。We do now employ pre-commit hooks that both check the code and the commit message.
Developers can skip them with
-n, but they rarely do and we always have another developer doing QA so things get noticed.The hook is important because it notices when files are broken, so that broken PHP or JS doesn't get committed at all.
Find them hook code at https://github.com/netresearch/git-client-hooks
We use a central server for development, and our git hooks get automatically installed because we provide a central git repository template that gets used automatically when you
git cloneorgit init.我宁愿不等待服务器端挂钩来控制推送。
您可以设置一个中间存储库，它将非常定期地获取每个开发人员的分支并审核每个新提交，如果提交未能满足某些预定义的标准，则发送电子邮件。
您还可以在中央存储库上进行预接收挂钩，但至少开发人员会更快地意识到潜在的问题。
I would rather not wait for a server-side hook to control a push.
You could setup an intermediate repo which would fetch each developer's branches very regularly and audit each new commit, sending an email if a commit fails to meet some pre-defined criteria.
You can also have pre-receive hook on the central repo, but at least the developer would be aware of a potential issue sooner.
我认为这里没有技术解决方案，但如果您真的想打扰别人，请将
phpcs集成到您的 CI 设置中，并开始在您的问题管理器中为其打开票证。 ;-)我认为这不是最好的主意，因为这实际上不是一个技术问题。您的问题不是提交前或提交后的挂钩，而是人们不这样做，而您认为必须强迫他们。
总而言之，我了解编码标准的重要性，并且我也执行一个编码标准，但它有一个社会组成部分（或方面）。
听起来和你一起工作的人要么还不知道更多，要么不愿意学习。因此，如果他们不太了解，您必须与他们合作并教他们遵守您的要求。这包括教他们为什么约定很重要，最后他们需要明白，只有一切都绿色之后，一项功能才算完成。
也许这需要项目管理（我猜就是你）将一个问题分解为多个任务，直到他们得到它：
phpcs（没有特定的顺序。;-)）
如果他们不愿意学习的你总是可以采取更严厉的措施。就像，我会慢慢开始，每周进行一次绩效评估（一对一的情况），并重申为什么他们不这样做。如果这没有帮助——我想你明白我的意思了。
I don't think there's a technical solution here but if you really want to bother people, then integrate
phpcsinto your CI setup and start opening tickets for it in your issue manager. ;-)I don't think that's the best idea though because it's really not a technical problem. Your issue is not a pre- or post-commit hook, but that people don't do it and you think you have to force them.
All in all, I understand the importance of a coding standard and I enforce one as well, but there's a social component (or aspect) to it.
It sounds like the people working with you either don't know any better (yet) or are un-willing to learn. So, in case they don't know any better you have to work with them and teach them to adhere to your requirements. That includes teaching them why conventions are important and in the end they need to understand that a feature is not done until everything is green.
Maybe that requires that project management (I gather that's you) breaks down an issue into multiple tasks until they get it:
phpcs(In no specific order. ;-))
If they're unwilling to learn you can always take more drastic measure. Like, I'd start off slowly and do a weekly performance review (1-on-1 situation) and reiterate why they don't do it. If that doesn't help -- I guess you catch my drift.
在 Drupal 项目中，我们最近迁移到了 Git，并正在研究类似的问题。在我们的例子中，我们不希望任何人检查模块的 LICENSE.txt 文件，因为我们的打包脚本会自动执行此操作。经过一番反复之后，我们想出了一个接收钩子，它不会拒绝错误的提交，但每次它检测到错误的提交（对于“错误”的某些定义）时，它都会自动在我们的错误中提交一个关键错误追踪器。这样，代码仍然会被提交，但模块维护者和相应的网站管理员团队都会立即收到通知，告知出现问题并应予以修复。您可以轻松地发送电子邮件或发送推文或任何其他您想要的通知。
实际上，我们还没有实现这一点，但这就是我们的 Git 实现团队一有时间就正在制定的计划。 :-)
基本上，除了重新表述之外，没有什么好的解决方案可以解决您所描述的问题；它不再是“阻止可检测的违规行为”，而是“报告可检测的违规行为”。我认为这是你能做的最好的事情。
In the Drupal project, we've recently migrated to Git and are looking at similar problems. In our case, we don't want anyone checking in a LICENSE.txt file for a module since our packaging scripts do that automatically. After some back and forth, what we came up with was a receive hook that doesn't reject a bad commit, but every time it detects a bad commit (for some definition of "bad") it automatically files a critical bug in our bug tracker. That way the code is still committed, but the module maintainer and the appropriate webmaster team both get notified immediately that something is amiss and should be fixed. You could just as easily send an email or send a tweet or whatever other notification you want.
Actually we haven't implemented that quite yet, but that's the plan we're working on as soon as our Git implementation team has time. :-)
Basically, there is no good solution for the problem you describe other than rephrasing it; instead of "block detectable violations" it becomes "report detectable violations." I think that's the best you can do.
使用jenkins + gerrit：
http://alblue. bandlem.com/2011/02/gerrit-git-review-with-jenkins-ci.html
如果构建失败，推送将被拒绝。
http://source.android.com/source/life-of-a -patch.html
泰瑞尔
use jenkins + gerrit:
http://alblue.bandlem.com/2011/02/gerrit-git-review-with-jenkins-ci.html
if your build fails, the push will be rejected.
http://source.android.com/source/life-of-a-patch.html
Tyrael
我不太会说“git-anese”，但在 Mercurial 中，有一个名为“changegroup”的挂钩选项，它本质上检查一组传入提交的“顶部”提交。也许社区中的某个人可以告诉您是否有等效的。 git 的“changegroup”？
https://www.mercurial-scm.org/wiki/Hook#The_changegroup_hook
I don't speek good 'git-anese', but in Mercurial there's a hook option called 'changegroup' that essentially checks the 'top' commit of a group of incoming commits. Maybe someone in the community can tell you if there's an equiv. of 'changegroup' for git?
https://www.mercurial-scm.org/wiki/Hook#The_changegroup_hook
我用了这个钩子：
http: //riticlog.thornet.net/2011/06/02/running-php-linter-before-pushing-changes-to-a-git-repository/
并修改它还可以使用 phpcs 测试代码。
可能包含一些错误，我有硬编码的 drupal 代码标准，但它有效！
http://pastebin.com/fEmN519B
I used this hook:
http://criticallog.thornet.net/2011/06/02/running-php-linter-before-pushing-changes-to-a-git-repository/
and modified it to also test code with phpcs.
Might contain some bugs and I have hardcoded drupal code standard but it works!
http://pastebin.com/fEmN519B
我没有直接使用预提交/预接收钩子等来回答这个问题。
我从另一种方式来解决这个问题，运行CI服务器，（我使用jenkins）运行phpcs和checkstyle插件詹金斯。
这允许我使构建失败并根据 checkstyle 报告向提交者发送电子邮件。
我可以选择设置阈值，因此如果最多有 5 个新风格的 violaions，我会得到一个不稳定的构建，但如果提交的数量超过 5 个，则会失败。
我还可以设置总体阈值，因此整个项目中超过 10 次违规会导致失败并向团队发送电子邮件。
如上所述，这可能是您的中间服务器。构建后操作可以包括推送到另一个 git 存储库。
I don't have an exact answer to this question directly using pre-commit/pre-recieve hooks etc.
I approach this from the other way, running a CI server, (I use jenkins) running phpcs and the checkstyle plug-in for Jenkins.
This allows me to fail the build and email the committer based on the checkstyle report.
Optionally I can set thresholds, so I get an unstable build if there are upto 5 new style violaions but a failure if more than 5 are committed.
Also I can set overall thresholds, so more than 10 violations in the whole project causes a failure and emails the team.
This could be your intermediate server as mentioned above. The post build actions can include a Push to another git repo.