git错误:挂钩拒绝更新_在开发工作流程中使用Git挂钩

git错误:挂钩拒绝更新

介绍 ( Introduction )

Git, a version control system created by Linus Torvalds, author of the Linux kernel, has become one of the most popular version control systems used globally. Certainly, this is because of its distributed nature, high performance and reliability.

Git是Linux内核的作者Linus Torvalds创建的版本控制系统，现已成为全球使用最广泛的版本控制系统之一。 当然，这是因为它具有分布式特性，高性能和可靠性。

In this tutorial, we'll look at git hooks. These hooks are a feature of git which furthers its extensibility by allowing developers to create event triggered scripts.

在本教程中，我们将介绍git hooks。 这些挂钩是git的功能，它允许开发人员创建事件触发的脚本，从而进一步扩展了其可扩展性。

We'll look through the different types of git hooks and implement a few to get you well on the way to customising your own.

我们将研究git钩子的不同类型，并实现一些钩子，以使您更好地自定义自己的钩子。

A git hook is a script that git executes before or after a relevant git event or action is triggered.

git钩子是在相关git事件或动作被触发之前或之后执行git的脚本。

Throughout the developer version control workflow, git hooks enable you to customise git's internal behaviour when certain events are trigerred.

在整个开发人员版本控制工作流程中，使用git hooks可以在触发某些事件时自定义git的内部行为。

They can be used to perform actions such as:

它们可用于执行以下操作：

1. Push to staging or production without leaving git
   在不离开git的情况下进行分期或生产
2. No need to mess with ssh or ftp
   无需弄乱ssh或ftp
3. Prevent commits through enforcing commit policy.
   通过执行提交策略来防止提交。
4. Prevent pushes or merges that don't conform to certain standards or meet guideline expectations.
   防止不符合某些标准或不符合准则期望的推送或合并。
5. Facilitate continuous deployment.
   促进持续部署。

This proves extremely helpful for developers as git gives them the flexibility to fine tune their development environment and automate development.

事实证明，这对开发人员非常有用，因为git使他们可以灵活地调整开发环境并自动进行开发。

先决条件 ( Prerequisites )

Before we get started, there are a few key programs we need to install.

在开始之前，我们需要安装一些关键程序。

1. git
   吉特
2. Node.js
   Node.js
3. bash
   重击

Confirm that you've installed them correctly by running the following in your terminal:

通过在终端中运行以下命令来确认已正确安装它们：

git --version && node --version && bash --version

You should see similar results

您应该会看到类似的结果

git version 2.7.4 (Apple Git-66)
v6.2.2
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)
Copyright (C) 2007 Free Software Foundation, Inc.

We'll be using the following directory structure, so go ahead and lay out your project like this.

我们将使用以下目录结构，因此请按照以下步骤布置您的项目。

+-- git-hooks
    +-- custom-hooks
    +-- src
    |   +-- index.js
    +-- test
    |   +-- test.js
    +-- .jscsrc

That's all for now as far as prerequisites go, so let's dive in.

就前提条件而言，目前仅此而已，所以让我们开始吧。

git钩子的类型 ( Types of git hooks )

git hooks can be categorised into two main types. These are:

git钩子可以分为两种主要类型。 这些是：

1. Client side hooks
   客户端挂钩
2. Server side hooks
   服务器端挂钩

In this tutorial, we'll focus more on client side hooks. However, we will briefly discuss server side hooks.

在本教程中，我们将更多地关注客户端挂钩。 但是，我们将简要讨论服务器端挂钩。

客户端挂钩 ( Client Side Hooks )

These are hooks installed and maintained on the developers local repository and are executed when events on the local repository are triggered. Because they are maintained locally, they are also known as local hooks.

这些是在开发人员本地存储库上安装和维护的挂钩，并在触发本地存储库上的事件时执行。 由于它们是本地维护的，因此也称为本地挂钩。

Since they are local, they cannot be used as a way to enforce universal commit policies on a remote repository as each developer can alter their hooks. However, they make it easier for developers to adhere to workflow guidelines like linting and commit message guides.

由于它们是本地的，因此它们不能用作在远程存储库上实施通用提交策略的方法，因为每个开发人员都可以更改其挂钩。 但是，它们使开发人员更容易遵守工作流程指南，例如棉绒和提交消息指南。

安装本地挂钩 (Installing local hooks)

Initialise the project we just created as a git repository by running

通过运行初始化我们刚刚创建为git存储库的项目

git init

Next, let's navigate to the .git/hooks directory in our project and expose the contents of the folder

接下来，让我们导航到项目中的.git / hooks目录，并显示文件夹的内容

cd ./.git/hooks && ls

We'll notice a few files inside the hooks directory, namely

我们会在hooks目录中注意到一些文件，即

applypatch-msg.sample           pre-applypatch.sample      pre-commit.sample prepare-commit-msg.sample   commit-msg.sample          post-update.sample pre-push.sample                      pre-rebase.sample            update.sample

These scripts are the default hooks that git has so helpfully gifted us with. Notice that their names make reference to git events like pushes, commits and rebases.

这些脚本是git如此有用地赠予我们的默认钩子。 注意，它们的名称引用了git事件，例如push，commit和rebase。

Useful in their own right, they also serve as a guideline on how hooks for certain events can be triggered.

它们本身很有用，也可作为如何触发某些事件的挂钩的指南。

The .sample extension prevents them from being run, so to enable them, remove the .sample extension from the script name.

.sample扩展名阻止它们运行，因此要启用它们，请从脚本名称中删除.sample扩展名。

The hooks we'll write here will be in bash though you can use Python or even Perl. Git hooks can be written in any language as long as the file is executable.

尽管您可以使用Python甚至是Perl，但我们将在此处编写的钩子仍是bash。 只要文件是可执行文件，就可以用任何语言编写Git挂钩。

We make the hook executable by using the chmod utility.

我们使用chmod实用程序使该钩子可执行。

chmod +x .git/hooks/<insert-hook-name-here>

执行顺序 (Order of execution)

Mimicking the developer workflow for the commit process, hooks are executed in the following hierarchy.

模仿提交过程的开发人员工作流，在以下层次结构中执行挂钩。

<pre-commit>
                                            |
                                      <prepare-commit-msg>
                                             |
                                        <commit-msg>
                                             |
                                     <post-commit>

预先提交 (pre-commit)

The pre commit hook is executed before git asks the developer for a commit message or creates a commit package. This hook can be used to make sure certain checks pass before a commit can be considered worthy to be made to the remote. No arguments are passed to the pre-commit script and if the script exists with a non zero value, the commit event will be aborted.

在git向开发人员询问提交消息或创建提交包之前，将执行pre commit钩子。 这个钩子可以用来确保某些检查通过，然后才认为值得对远程进行提交。 没有参数传递到预提交脚本，并且如果脚本存在非零值，则提交事件将被中止。

Before we get into anything heavy, let's create a simple pre-commit hook to get us comfortable.

在进行任何繁重的工作之前，让我们创建一个简单的预提交钩子，以使我们感到舒适。

Create a pre-commit hook inside the .git/hooks directory like this.

像这样在.git / hooks目录中创建一个预提交钩子。

touch pre-commit && vi pre-commit

Enter the following into the pre-commit hook file

在预提交的钩子文件中输入以下内容

#!/bin/bash

echo "Can you make a commit? Well, it depends."
exit 1

Save and exit the editor by running:

通过运行以下命令保存并退出编辑器：

escthen :wq

Don't forget to make the hook file executable by running:

不要忘记通过运行以下命令使钩子文件可执行：

chmod + x .git/hooks/pre-commit

Let's write out some code to test our newly minted hook against. At the root of our project, create a file called hello-world.py

让我们写一些代码来测试我们新创建的钩子。 在我们项目的根目录下，创建一个名为hello-world.py的文件

touch hello-world.py

Inside the file, enter the following:

在文件内，输入以下内容：

print ('Hello Hooks') # python v3
# print 'Hello Hooks' # python v2

Next let's add the file into our git staging environment and begin a commit.

接下来，让我们将文件添加到git临时环境中并开始提交。

git add . && git commit

Are you surprised that git doesn't let us commit our work?

您对git不允许我们提交工作感到惊讶吗？

As an experiment, modify the last line in the pre-commit hook we created from exit 1 to exit 0 and trigger another commit.

作为实验，将我们从exit 1创建的pre-commit挂钩中的最后一行修改为exit 0然后触发另一个提交。

Now that we understand that a hook is just an event triggered script, let's create something with more utility.

既然我们已经了解了钩子只是事件触发的脚本，那么让我们使用更多的实用工具创建东西。

In our example below, we want to make sure that all the tests for our code pass and that we have no linting errors before we commit.

在下面的示例中，我们要确保在提交代码之前，所有对我们代码的测试均通过，并且不存在掉毛错误。

We're using mocha as our javascript test framework and jscs as our linter.

我们使用mocha作为我们的javascript测试框架，使用jscs作为我们的linter 。

Fill the following into the .git/hooks/pre-commit file

将以下内容填充到.git / hooks / pre-commit文件中

#!/bin/bash

# Exits with non zero status if tests fail or linting errors exist
num_of_failures=`mocha -R json | grep failures -m 1 | awk '{print $2}' | sed 's/[,]/''/'`

errors=`jscs -r inline ./test/test.js`
num_of_linting_errors=`jscs -r junit ./test/test.js | grep failures -m 1 | awk '{print $4}' | sed 's/failures=/''/' | sed s/">"/''/ | sed s/\"/''/ | sed s/\"/''/`

if [ $num_of_failures != '0' ]; then
  echo "$num_of_failures tests have failed. You cannot commit until all tests pass.
        Commit exiting with a non-zero status."
  exit 1
fi

if [ $num_of_linting_errors !=  '0' ]; then
  echo "Linting errors present. $errors"
  exit 1
fi

Save the document and exit the vi editor as usual by using,

保存文档，并照常使用以下方法退出vi编辑器，

escthen :wq

The first line of the script indicates that we want the script to be run as a bash script. If the script was a python one, we would instead use

该脚本的第一行表示我们希望该脚本作为bash脚本运行。 如果脚本是python脚本，我们将改用

#!/usr/bin/env python

Make the file executable like we mentioned before by running

通过运行使文件像我们之前提到的那样可执行

chmod +x .git/hooks/pre-commit

To give our commit hook something to test against, we'll be creating a method that returns true when an input string contains vowels and false otherwise.

为了给我们的提交钩子提供一些测试依据，我们将创建一个方法，当输入字符串包含元音时返回true ，否则返回false 。

Create and populate a package.json file at the root of our git-hooks folder by running

通过运行以下命令在我们的git-hooks文件夹的根目录创建并填充package.json文件

npm init --yes

Install the project dependencies like this:

像这样安装项目依赖项：

npm install chai mocha jscs --save-dev

Let's write a test for our prospective hasVowels method.

让我们为我们的预期hasVowels方法编写一个测试。

git-hooks/test/test.js

git-hooks / test / test.js

const expect = require('chai').expect;
require('../src/index');

describe('Test hasVowels', () => {
  it('should return false if the string has no vowels', () => {
    expect('N VWLS'.hasVowels()).to.equal(false);
  });
  it('should return true if the string has vowels', () => {
    expect('No vowels'.hasVowels()).to.equal(true)

    // Introduce failing test
    expect('Has vowels'.hasVowels()).to.equal(false);
  });
});

git-hooks/src/index.js

git-hooks / src / index.js

// Method returns true if a vowel exists in the input string. Returns false otherwise.
String.prototype.hasVowels = function hasVowels() {
  const vowels = new RegExp('[aeiou]', 'i');
  return vowels.test(this);
};

To configure the jscs linter, fill the following into the .jscsrc file we'd created in the beginning.

要配置jscs linter ，请将以下内容填充到我们在一开始创建的.jscsrc文件中。

.jscsrc

.jscsrc

{
    "preset": "airbnb",
    "disallowMultipleLineBreaks": null,
    "requireSemicolons": true
}

Now add all the created files into the staging environment and trigger a commit.

现在，将所有创建的文件添加到暂存环境中并触发提交。

git add .  && git commit

What do you think will happen?

您认为会发生什么？

You're right. Git prevents us from making a commit. Rightfully so, because our tests have failed. Worry not. Our pre-commit script has helpfully provided us with hints regarding what could be wrong.

你是对的。 Git阻止我们进行提交。 没错，因为我们的测试失败了。 不用担心 我们的预提交脚本有助于向我们提供有关可能出问题的提示。

This is what it tells us:

这就是告诉我们的：

1 tests have failed. You cannot commit until all tests pass.
        Commit exiting with a non-zero status.

If you can't take my word for it, the screenshot below serves as confirmation.

如果您无法接受，请使用以下屏幕截图进行确认。

Let's fix things. Edit line 13 in test/test.js to

让我们解决问题。 将test / test.js中的 第13行编辑为

expect('Has vowels'.hasVowels()).to.equal(true);

Next add the files to your staging environment, git add . like we did before and git commit

接下来，将文件添加到您的暂存环境中， git add . 像我们之前所做的和git commit

Git still prevents us from committing.

Git仍然阻止我们提交。

Linting errors present. ./test/test.js: line 10, col 49, requireSemicolons: Missing semicolon after statement

Edit line 10 in test/test.js to

将test / test.js中的 第10行编辑为

expect('No vowels'.hasVowels()).to.equal(true);

Now, running git commit after git add . should provide no challenges because our tests and linting have both passed.

现在，在git add .之后运行git commit git add . 因为我们的测试和棉绒都通过了，所以应该没有挑战。

You can skip the pre-commit hook by running git commit --no-verify.

您可以通过运行git commit --no-verify来跳过预提交钩子。

准备提交消息 (prepare-commit-msg)

The prepare-commit-msg hook is executed after the pre-commit hook and its execution populates the vi editor commit message.

在预提交钩子之后执行prepare-commit-msg钩子，并且其执行将填充vi编辑器提交消息。

This hook takes one, two or three arguments.

这个钩子接受一个，两个或三个参数。

1. The name of the file that contains the commit message to be used.
   包含要使用的提交消息的文件的名称。
2. The type of commit. This can be message, template, merge or squash.
   提交的类型。 这可以是消息，模板，合并或压缩。
3. The SHA-1/hash of a commit (when operating on an existing commit).
   提交的SHA-1 /哈希值（对现有提交进行操作时）。

In the code below, we're electing to populate the commit editor workspace with a helpful commit message format reminder prefaced by the name of the current branch.

在下面的代码中，我们选择使用一个有用的提交消息格式提醒（以当前分支的名称为开头）填充提交编辑器工作区。

.git/hooks/prepare-commit-msg

.git / hooks / prepare-commit-msg

#!/bin/bash

# Result will be output in place of the default commit message on running git commit
current_branch=`git rev-parse --abbrev-ref HEAD`

echo "#$current_branch Commit messages should be of the form [#StoryID:CommitType] Commit Message." > $1

Running git commit will yield the following in the commit text editor

运行git commit将在提交文本编辑器中产生以下内容

#$master Commit messages should be of the form [#StoryID:CommitType] Commit Message.

We can continue to edit our commit message and exit out of the editor as usual.

我们可以继续编辑提交消息，然后照常退出编辑器。

提交消息 (commit-msg)

This hook is executed after the prepare-commit-msg hook. It can be used to reformat the commit message after it has been input or to validate the message against some checks. For example, it could be used to check for commit message spelling errors or length, before the commit is allowed.

该挂钩在prepare-commit-msg挂钩之后执行。 输入提交消息后，可用于重新格式化提交消息，或通过某些检查来验证消息。 例如，可以在允许提交之前检查提交消息的拼写错误或长度。

This hook takes one argument, that is the location of the file that holds the commit message.

该钩子接受一个参数，即保存提交消息的文件的位置。

.git/hooks/commit-msg

.git / hooks / commit-msg

#!/bin/bash
#!/bin/bash

# Validates whether commit message is of a certain format.
# Aborts commit if message is unsatisfactory

# Standard commit from Pivotal Tracker [#135316555:Feature]Create Kafka Audit Trail
commit_standard_regex='[#[0-9]{9,}:[a-z]{3,}]:[a-z].+|merge'
error_message="Aborting commit. Please ensure your commit message meets the
               standard requirement. '[#StoryID:CommitType]Commit Message'
              Use '[#135316555:Feature]Create Kafka Audit Trail' for reference"


if ! grep -iqE "$commit_standard_regex" "$1"; then
    echo "$error_message" >&2
    exit 1
fi

In the code above, we're validating the user supplied commit message against a standard commit using a regular expression. If the supplied commit does not conform to the regular expression, an error message is directed to the shell's standard output, the script exits with a status of one and the commit is aborted.

在上面的代码中，我们正在使用正则表达式针对标准提交验证用户提供的提交消息。 如果提供的提交不符合正则表达式，则会将错误消息定向到Shell的标准输出，脚本以状态1退出并中止提交。

Go ahead. Create a change and try make a commit of a form other than [#135316555:Chore]Test commit-msg hook

前进。 创建一个更改，然后尝试提交除[#135316555:Chore]Test commit-msg hook以外的其他形式的[#135316555:Chore]Test commit-msg hook

Git will abort the commit process and give you a handly little tip regarding the format of your commit message.

Git将中止提交过程，并为您提供有关提交消息格式的一些小技巧。

提交后 (post-commit)

This hook is executed after the commit-msg hook and since the commit has already been made it cannot abort the commit process.

该挂钩在commit-msg挂钩之后执行，并且由于已经进行了提交，因此无法中止提交过程。

It can however be used to notify the relevant stakeholders that a commit has been made to the remote repository. We could write a post-commit hook, say, to email our project team lead whenever we make a commit to the organisation's remote repository.

但是，它可以用于通知相关的利益相关者已经对远程存储库进行了提交。 例如，只要我们对组织的远程存储库进行提交，我们就可以编写一个提交后钩子，以向我们的项目团队负责人发送电子邮件。

In this case, let's congratulate ourselves for our hard work.

在这种情况下，让我们祝贺我们的辛勤工作。

.git/hooks/post-commit

.git / hooks / post-commit

#!/bin/bash

say Congratulations! You\'ve just made a commit! Time for a break.

结帐后 (post-checkout)

The post-checkout hook is executed after a successful git checkout is performed. It can be used to conveniently delete temporary files or prepare the checked out development environment by performing installations.

成功执行git checkout后，将执行post-checkout挂钩。 它可用于通过执行安装方便地删除临时文件或准备检出的开发环境。

Its exit status does not affect the checkout process.

它的退出状态不会影响结帐过程。

In the hook below, before checkout to another branch, we'll pull changes made by others on the remote branch and perform some installation.

在下面的挂钩中，签出到另一个分支之前，我们将拉取其他人在远程分支上所做的更改并执行一些安装。

.git/hooks/post-checkout

.git / hooks / post-checkout

#!/bin/bash

# Executed immediately after a git checkout
repository_name=`basename`git rev-parse --show-toplevel``
current_branch=`git rev-parse --abbrev-ref HEAD`present_working_directory=`pwd`requirements=`ls | grep 'requirements.txt' `echo "Pulling remote branch ....."
git pull origin $current_branch

echo

echo "Installing nodeJS dependencies ....."
npm install

echo

echo "Installing yarn package ....."
npm install yarn
echo "Yarning dependencies ......"
yarn

echo

# Only do this if you find a requirements.txt file at the root of the project
if [ $present_working_directory == $repository_name ] && [ $requirements == 'requirements.txt']; then
  echo "Creating virtual environments for project ......."
  source`which virtualenv`
  echo
  mkvirtualenv $repository_name/$current_branch
  workon $repository_name/$current_branch
  echo "Installing python dependencies ......."
  pip install -r requirements.txt
fi

Don't forget to make the script executable.

不要忘记使脚本可执行。

To test the script out, create another branch and check out to it like this.

要测试脚本，请创建另一个分支并以这种方式签出。

git checkout -b <new-branch>

变基前 (pre-rebase)

This hook is executed before a rebase and can be used to stop the rebase if it is not desirable.

该挂钩在重新设置基准之前执行，如果不希望使用该钩子，则可以用来停止重新确定基准。

It takes one or two parameters:

它需要一个或两个参数：

1. The upstream repository
   上游仓库
2. The branch to be rebased. (This parameter is empty if the rebase is being performed on the current branch)
   要重新建立分支的分支。 （如果正在当前分支上执行变基，则此参数为空）

Let's outlaw all rebasing on our repository.

让我们取缔所有基于存储库的重新定律。

.git/hooks/pre-rebase

.git / hooks / pre-rebase

#!/bin/bash

echo " No rebasing until we grow up. Aborting rebase."
exit 1

Phew! We've gone through quite a number of client side hooks. If you're still with me, good work!

！ 我们已经经历了很多客户端挂钩。 如果您还和我在一起，那就干得好！

持久钩 (Persisting hooks)

I've got some bad news and good news. Which one would you like first?

我有一些坏消息和好消息。 您首先要选哪个？

The bad

不好

The .git/hooks directory is not tagged by version control and so does not persist when we clone a remote repository or when we push changes to a remote repository. This is why, we'd earlier stated that local hooks cannot be used to enforce commit policies.

.git/hooks目录没有版本控制标记，因此当我们克隆远程存储库或将更改推送到远程存储库时，该.git/hooks不会持久存在。 这就是为什么我们前面已经说过本地钩子不能用于强制落实策略的原因。

The good

好的

Now before you start sweating, there are a few ways we can get around this.

现在，在开始流汗之前，有几种方法可以解决此问题。

1. We can use symbolic links or symlinks to link our custom hooks to the ones in the .git/hooks folder.
   我们可以使用符号链接或符号链接将我们的自定义钩子链接到.git/hooks文件夹中的.git/hooks 。

Create a pre-rebase file in our custom-hooks directory and copy the pre-rebase hook we created in .git/hooks/pre-rebase into it. Next, the rm command removes the pre-rebase hook in .git/hooks

在我们的custom-hooks目录中创建一个预变基文件，并将在.git/hooks/pre-rebase创建的预变基钩复制到该文件中。 接下来， rm命令删除.git / hooks中的pre-rebase 钩子

touch custom-hooks/pre-rebase && cp .git/hooks/pre-rebase custom-hooks/pre-rebase && rm -f .git/hooks/pre-rebase

Next, use the ln command to link the pre-rebase file in custom-hooks to the .git/hooks directory.

接下来，使用ln命令将custom-hooks的pre-rebase文件链接到.git/hooks目录。

# ln -s <source> <target>
ln -s custom-hooks/pre-rebase .git/hooks/pre-rebase

To confirm that the files have been linked, run the following

要确认文件已链接，请运行以下命令

ls -la .git/hooks

The output for the pre-rebase file should be similar to this:

pre-rebase文件的输出应与此类似：

lrwxr-xr-x   1 emabishi  staff    23B Dec 27 14:57 pre-rebase -> custom-hooks/pre-rebase

Notice the l character prefixing the filesystem file permissions line.

请注意，在文件系统文件许可权行之前加上l字符。

To unlink the two files,

要取消链接这两个文件，

unlink .git/hooks/pre-rebase

or

要么

rm -f .git/hooks/pre-rebase

1. We can create a directory to store our hooks outside the .git/hooks directory. We've already done this by storing our pre-rebase hook in the custom-hooks directory. Like our other files, this folder can be pushed to our remote repository.
   我们可以创建一个目录来将钩子存储在.git / hooks目录之外。 我们已经通过将re-base钩子存储在custom-hooks目录中来完成此操作。 与其他文件一样，该文件夹也可以推送到我们的远程存储库。

服务器端挂钩 ( Server Side Hooks )

These are hooks that are executed in a remote repository on the triggering of certain events.

这些是在某些事件触发时在远程存储库中执行的挂钩。

Is it clear now? Client side hooks respond to events on a local repository whilst server side hooks respond to events triggered on a remote repository.

现在清楚了吗？ 客户端挂钩响应本地存储库上的事件，而服务器挂钩响应远程存储库上触发的事件。

We'd come across some of them when we listed the files in the .git/hooks directory.

当我们在.git/hooks目录中列出文件时，我们会遇到其中的一些。

Let's look at a few of these hooks now.

现在让我们看一下其中的一些钩子。

执行顺序 (Order of execution)

The server side hooks we'll look at here are executed with the following heirarchy.

我们将在下面介绍的服务器端挂钩是通过以下层次结构执行的。

<pre-receive>
                                           |
                                       <update>
                                           |
                                       <post-receive>

预先接收 (pre-receive)

This hook is triggered on the remote repository just before the pushed files are updated and can abort the receive process if it exists with a non-zero status.

在挂载文件更新之前，此挂钩在远程存储库上被触发，并且如果存在非零状态，则可以中止接收过程。

Since the hook is executed just before the remote is updated, it can be used to enforce commit policies and reject the entire commit if it is deemed unsatisfactory.

由于挂钩是在远程更新之前执行的，因此可以用来执行提交策略，并在认为不满意时拒绝整个提交。

更新 (update)

The update hook is called after the pre-receive hook and functions similarly. The difference is that ii filters each commit ref made to the remote repository independently. It can be used as a fine tooth comb to reject or accept each ref being pushed.

在预接收钩子之后调用更新钩子，其功能类似。 区别在于ii会分别过滤对远程存储库所做的每个提交引用。 它可以用作细齿梳来拒绝或接受每个推入的参考。

接收后 (post-receive)

This hook is triggered after an update has been done on the remote repository and so cannot abort the update process. Like the post-commit client-side hook, it can be used to trigger notifications on a successful remote repository update.

在远程存储库上完成更新后，将触发此挂钩，因此无法中止更新过程。 与提交后客户端挂钩一样，它可用于在成功进行远程存储库更新时触发通知。

In fact, it is more suited for this because a log of the notifications will be stored on a remote server.

实际上，它更适合于此，因为通知日志将存储在远程服务器上。

结论 ( Conclusion )

We've looked at quite a few hooks which should get you up and running. However, I'd love for you to do some more exploration.

我们已经研究了很多挂钩，这些挂钩应该可以使您启动并运行。 但是，我希望您能进行更多探索。

For a more comprehensive look at git hooks, I'd like to direct you to:

要更全面地了解git hooks，我想指导您：

• The official git guide on hooks
  钩子上的官方git指南
• The git man page on hooks
  钩子上的git手册页
• The Atlassian git hooks guide
  Atlassian git钩子指南

It's a brave new world out there when it comes to git hooks, so luckily, you don't always have to write your own custom scripts. You can find a pretty comprehensive list of useful frameworks here .

当涉及到git hook时，这是一个勇敢的新世界，所以幸运的是，您不必总是编写自己的自定义脚本。 您可以在此处找到非常全面的有用框架列表。

All the code we've written can be found here .

我们编写的所有代码都可以在这里找到。

I'd love to hear some feedback on this guide and on git hooks in general. Don't be shy. Drop me a line in the comments form below.

我希望听到一些有关本指南和git hooks的反馈。 别害羞 在下面的评论表格中给我一行。

翻译自: https://scotch.io/tutorials/using-git-hooks-in-your-development-workflow

git错误:挂钩拒绝更新