git本地没有绿钩
When certain commands are run, Git searches the .git/hooks directory for suitable hook scripts which are then executed if found. You’ll find a small set of example scripts there (you can activate them by renaming them to remove the .sample prefix and setting their executable bit), and a complete list of hooks can be found in the githooks(5) man page.
当运行某些命令时，Git会在.git/hooks目录中搜索合适的钩子脚本，如果找到，则将其执行。 您将在其中找到一.sample示例脚本(可以通过重命名它们以删除.sample前缀并设置其可执行位来激活它们)，并且在githooks(5)手册页中可以找到钩子的完整列表。
This article suggests a handful of hooks which can streamline development and help improve your efficiency.
本文提出了一些挂钩，可以简化开发并帮助提高效率。
棉签 (Lint Checks)
There’s really no excuse, yet I’ll admit even I’ve done this once or twice before: commit syntactically broken code. But what if a lint check could be performed automatically as part of the commit process to safeguard from this? And if you run a lint check manually before each commit, automating it can protect against the occasional moment of forgetfulness.
确实没有任何借口，但是即使我之前做过一次或两次，我都承认：提交语法错误的代码。 但是，如果可以在提交过程中自动执行棉绒检查以防止这种情况发生怎么办？ 而且，如果您在每次提交之前手动运行一次棉绒检查，将其自动化可以防止偶尔的健忘。
The following shell code can be saved as .git/hooks/pre-commit (or appended if pre-commit hook code already exists) to trigger an automatic check whenever a commit is made:
可以将以下shell代码保存为.git/hooks/pre-commit (如果已经存在pre-commit钩子代码，则将其保存)以在进行提交时触发自动检查：
[shell]#!/bin/bash
[shell]＃！/ bin / bash
git diff –cached –name-status –diff-filter=ACMR | while read STATUS FILE; do if [[ "$FILE" =~ ^.+(php|inc)$ ]]; then php -l "$FILE" 1> /dev/null if [ $? -ne 0 ]; then echo "Aborting commit due to files with syntax errors" >&2 exit 1 fi fi done[/shell]
git diff –cached –名称状态–diff-filter = ACMR | 同时读取状态文件； 如果[[“ $ FILE” =〜^。+(php | inc)$]]来做； 然后php -l“ $ FILE” 1> / dev / null如果[$？ -ne 0]; 然后回显“由于语法错误导致文件中止提交”>＆2退出1 fi fi完成[/ shell]
git diff reports on what’s changed between commits, and the options above return only the files that have been added (A), copied (C), modified (M), or renamed (R) in the staged commit. The files with an extension of .php or .inc are targeted for a lint check, and a failed check will exit the script with a non-zero return code and thus abort the commit itself. Your code may be buggy, but at least you know it’s got all of its semicolons.
git diff报告git diff提交之间的更改，以上选项仅返回在暂存提交中已添加(A)，已复制(C)，已修改(M)或重命名(R)的文件。 扩展名为.php或.inc的.php将用于执行lint检查，如果检查失败，则会以非零返回码退出脚本，从而中止提交本身。 您的代码可能有错误，但是至少您知道它包含所有分号。
拼写检查提交消息 (Spell-Check Commit Messages)
Developers are supposed to be meticulous and have an eye for detail (at least that’s what we all put on our CV when looking for a job), so a commit message with bad spelling can be embarrassing.
开发人员应该是细心的，并且注重细节(至少这是我们在找工作时都放在简历上的东西)，所以拼写错误的提交信息可能会令人尴尬。
Commit messages give the reader a broad idea of what changes were made in a commit and thus have the potential to be read by a large audience, from other developers to compliance auditors. Even if you code only for yourself, writing professional messages is a good habit to develop, and automating a “second set of eyes” can help reduce speling erors in your comit messeges.
提交消息使读者对提交中所做的更改有广泛的了解，因此有可能被其他开发人员到法规遵从性审核员的广大读者阅读。 即使您只为自己编写代码，编写专业消息也是一种养成的好习惯，而自动化“第二只眼睛”可以帮助减少常见问题中的错误 。
The following code can be saved as .git/hooks/post-commit (or appended); it calls Aspell and outputs a list of suspect words. If there are errors, you can immediately fix the commit message by running git commit --amend.
以下代码可以另存为.git/hooks/post-commit (或附加)； 它调用Aspell并输出可疑单词列表。 如果有错误，您可以通过运行git commit --amend立即修复提交消息。
[shell]#!/bin/bash
[shell]＃！/ bin / bash
ASPELL=$(which aspell) if [ $? -ne 0 ]; then echo "Aspell not installed – unable to check spelling" >&2 exit fi
ASPELL = $(哪个aspell)，如果[$？ -ne 0]; 然后回显“未安装Aspell –无法检查拼写”>＆2退出fi
AWK=$(which awk) if [ $? -ne 0 ]; then echo "Awk not installed – unable to filter spelling errors" >&2 WORDS=$($ASPELL list < "$1") else WORDS=$($ASPELL list < "$1" | $AWK ‘!_[$0]++’) fi
AWK = $(哪个awk)如果[$？ -ne 0]; 然后回显“未安装Awk –无法过滤拼写错误”>＆2 WORDS = $($ ASPELL list <“ $ 1”)否则WORDS = $($ ASPELL list <“ $ 1” | $ AWK'！_ [$ 0] ++ ')fi
if [ -n "$WORDS" ]; then echo "Possible spelling errors found in commit message: " $WORDS >&2 fi[/shell]
如果[-n“ $ WORDS”]; 然后回显“在提交消息中发现可能的拼写错误：” $ WORDS>＆2 fi [/ shell]
You can also compile a supplemental dictionary using identifiers extracted from your project’s source code (perhaps triggered with a post-checkout hook) and pass it to Aspell with --extra-dicts to reduce the number of false positives. Parsing code and managing dictionary files is beyond the scope of this article though, so I’ll leave it as an exercise for you to explore later.
您还可以使用从项目的源代码中提取的标识符(可能通过结帐后挂钩触发)来编译补充词典，然后使用--extra-dicts dicts将其传递给Aspell，以减少误报的数量。 但是，解析代码和管理字典文件不在本文的讨论范围之内，因此，我将其作为练习供您以后进行探索。
检查标准 (Checking Standards)
I don’t know of any scientific research that definitively proves formatting standards reduce cognitive friction when reading code. Most of the standards irritatingly target only low-hanging fruit anyway: capitalize something this way, place your braces here and not there, etc. Standards that enforce good architectural design and address specific interoperability concerns have more merit in my opinion.
我不知道有任何科学研究能明确证明格式化标准可以减少阅读代码时的认知摩擦。 无论如何，大多数标准都只针对低垂的水果而烦人：以这种方式利用某些东西，将括号放在这里而不是那里等。我认为，实施良好的架构设计并解决特定的互操作性问题的标准更具优势。
But if you’re working with people who think 81 characters on a line is the eighth deadly sin, it might help smooth political friction by making sure your code conforms to an adopted formatting standard. The following code can be used as a post-commit hook (.git/hooks/post-commit) to automatically check for formatting violations.
但是，如果您与认为行中的81个字符是第八个致命罪过的人一起工作，则可以通过确保您的代码符合所采用的格式标准来缓解政治冲突。 以下代码可用作提交后挂钩( .git/hooks/post-commit )，以自动检查格式冲突。
[shell]#!/bin/bash
[shell]＃！/ bin / bash
DIR=$(git rev-parse –show-toplevel) EMAIL=$(git config user.email) TMPFILE=$(mktemp)
DIR = $(git rev-parse –show-toplevel)EMAIL = $(git config user.email)TMPFILE = $(mktemp)
git diff –cached –name-status –diff-filter=ACMR | while read STATUS FILE; do if [[ "$FILE" =~ ^.+(php|inc)$ ]]; then phpcs –standard=zend "$FILE" >> $TMPFILE fi done
git diff –cached –名称状态–diff-filter = ACMR | 同时读取状态文件； 如果[[“ $ FILE” =〜^。+(php | inc)$]]来做； 然后phpcs –standard = zend“ $ FILE” >> $ TMPFILE fi完成
if [ -s $TMPFILE ]; then mailx -s "PHPCS: Coding Standards Violations" $EMAIL < $TMPFILE fi rm $TMPFILE[/shell]
如果[-s $ TMPFILE]； 然后mailx -s“ PHPCS：违反编码标准” $ EMAIL <$ TMPFILE固定$ TMPFILE [/ shell]
The script uses PHP CodeSniffer to scan each PHP file in the commit for violations and then sends an email listing the violations that were found. If you’re using one of those buzzword productivity approaches like Getting Things Done to manage your email, you can set up an email filter that routes the received emails directly to your TODO folder to make sure you fix the violations in a timely manner.
该脚本使用PHP CodeSniffer扫描提交中的每个PHP文件是否存在违规行为，然后发送一封电子邮件，列出发现的违规行为。 如果您使用“完成事情”等流行语来管理电子邮件中的一种，则可以设置电子邮件过滤器，将接收到的电子邮件直接路由到您的TODO文件夹，以确保您及时解决违规问题。
自动运行作曲家 (Automatically Run Composer)
So far we’ve seen hooks that focus on commits and the development process, but there are also some useful hooks that can be executed at other points in a Git workflow, even deployment. Suppose you have a remote repository set up on a production server, and pushing to it is your approach to deployment.
到目前为止，我们已经看到了有关提交和开发过程的钩子，但是也有一些有用的钩子可以在Git工作流甚至部署中的其他位置执行。 假设您在生产服务器上设置了一个远程存储库，并且将其推送到您的部署方法中。
Further suppose that you use Composer to manage your application’s dependencies and you only keep your own code in your repository. This means you still have additional work to do after a push, either copying the dependencies over manually or ssh-ing into the server to run composer.phar update.
进一步假设您使用Composer来管理应用程序的依赖关系，并且只在存储库中保留自己的代码。 这意味着在推送之后您仍然还有其他工作要做，要么手动复制依赖项，要么将其ssh-sing到服务器中以运行composer.phar update 。
To make your life easier, putting this in the remote repository’s .git/hooks/post-receive file for a post-receive hook will run Composer automatically.
为了使您的生活更轻松，将其放入远程存储库的.git/hooks/post-receive文件中以进行接收后挂钩将自动运行Composer。
[shell]#!/bin/bash
[shell]＃！/ bin / bash
DIR=$(git rev-parse –show-toplevel)
DIR = $(git rev-parse –show-toplevel)
if [ -e "$DIR/composer.json" ]; then if [ -d "$DIR/vendor" ]; then composer.phar install else composer.phar update fi fi[/shell]
如果[-e“ $ DIR / composer.json”]; 然后，如果[-d“ $ DIR / vendor”]； 然后composer.phar安装else composer.phar更新fi fi [/ shell]
结论 (Conclusion)
In this article I shared a handful of hooks that can hopefully streamline how you develop your applications and make you more efficient. Feel free to share whether you are taking advantage of this powerful feature or not, and maybe even some of your own hooks in the comments below.
在本文中，我分享了一些挂钩，希望可以简化您开发应用程序的方式并提高您的效率。 随时分享您是否正在使用此强大功能，甚至可能会在下面的评论中分享一些自己的想法。
Here are a few additional resources for hints, tips, and inspiration:
以下是一些有关提示，技巧和灵感的其他资源：
Ben Kulbertis – Synchronizing a MySQL Database with Git and Git Hooks
git本地没有绿钩
7万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
