Git接收后挂钩不起作用？

Question

I'm trying to set up a Git repo so that whenever I push to master on GitHub from my local machine, the new changes are automatically deployed on a remote server. But I think I'm missing something fundamental about how hooks work.

I've set up a .git/hooks/post-receive script on the remote server that looks like this:

#!/bin/sh

GIT_WORK_TREE=/home/me/webapps/myapp git checkout -f master
GIT_WORK_TREE=/home/me/webapps/myapp git reset --hard

If I run it, it does this:

$ /home/me/webapps/myapp/.git/hooks/post-receive
Already on 'master'
Your branch is up-to-date with 'origin/master'.
HEAD is now at 527755e Initial commit

However, 527755e is not the latest head available on GitHub - I've pushed more changes since then. It's the head on the remote machine.

I think I must be missing something. How does the hook on the remote server "know" when I push to master?

How do I need to change this so that pushes from local are automatically copied to the remote server?

Answer 1

I think I must be missing something. How does the hook on the remote server "know" when I push to master?

It doesn't—but if set up correctly, it may not have to. "Correctly" depends on various conditions.

Remember, each Git repository is independent of any other Git repository and controls its own destiny. It may help to give each repository a name: A, B, and C; or Alice, Bob, and Carol; or whatever. Here, let's suppose there are exactly two repositories: yours, which is repo R, and the server's, which is repo S.

There are things that you do on repo R that affect R. These include:

• checking out specific commits, perhaps by branch name;
• adding new commits;
• moving branch names from one commit to another;
• running git fetch .

The last one of these has your Git call up another Git, such as the one at S, and collect commits from it. After collecting commits, your Git alters your Git's remote-tracking names such as origin/master . This has no effect on your own branch names, which are not in this remote-tracking name space and do not start with origin/ .

Someone on the server, in control of repo S, can do the same sorts of things over there, but typically no one actually works on the server. In fact, the repository on S is typically a bare repository specifically so that no one on S can do any work on it. It's this lack-of-work that specifically makes it possible for S to be a target of git push (modulo the newfangled updateInstead stuff mentioned below).

When Git is a target of git push , it:

• receives some objects, typically commits, from some other repository; then
• receives some name-update requests or commands from whoever is sending those commits.

Note that these name updates are not moved into some separate name-space. This is very different from git fetch ; we'll come back to this in a moment.

The receiving Git on S does all this using git receive-pack , which is not a command anyone would normally run themselves. The receive-pack command, though, runs a bunch of hooks. The current complete list is:

• pre-receive: once, before starting any name updates;
• update: once per name-update;
• post-receive: once, after doing all name updates;
• post-update: once, after doing all name updates;
• push-to-checkout: once, if and when pushing to the current branch of a non-bare repository in which the configuration key receive.denyCurrentBranch is set to updateInstead .

but some of these are new in newer versions of Git. The standard three available even in very old versions of Git are pre-receive, update, and post-receive. (For more on what each hook can do, consult the githooks documentation , preferably the documentation for your particular installation since these have changed over time.)

So what does all this mean in the end?

Remember, whoever is doing the git push generally requests that the server set repo S's branches . Hence, after S gets and accepts a request to change its own master , the name master in repository S means the commit we just received and accepted .

Since S runs these hooks before, during, and just after receiving and executing the name-update requests, we can have S run:

git --work-tree=<path> checkout <args>

The --work-tree=<path> , or its equivalent using the GIT_WORK_TREE environment variable, overrides the "bare"-ness of the bare repository S so that S becomes a non-bare repository with a work-tree. Note that S's index, which indexes this (single) work-tree, remains associated with S itself (it's in the Git directory, as the file named index ): there is only one default index, so it can only index one work-tree. If some branch name(s) are updated, any git checkout <branch-name> may now check out some other commit, different from the one previously checked-out.

There is an obvious potential race condition here: what if two or more users on some repositories Q and R run git push to S simultaneously , asking S to change its master from, say, aaaaaaa... to bbbbbbb... (Q) and ccccccc... (R)? For the name update itself, one of the two will "win" the race and set the name-to-hash mapping first. The other will see that the name master is locked and be told to back off try again. So the true "simultaneous" case is OK. However, we can also have one succeed in updating master and then start the post-receive hook. The other one can then come along and also update master . The first post-receive hook might see either version of master , and the second post-receive hook might begin running while the first is still running.

There appears to be no code in modern Git to prevent this. Older versions of Git left lock files around during much of the operation that prevented a second receive-pack from starting, but I think even those unlocked the repository before running the post-receive hook. If you want true atomicity and are doing something complicated, it might be wise to implement your own locking.

For git checkout , though, this should mostly be harmless: the one that "wins the race" will either check out the old master or the new master —it literally cannot see any other value for the reference—and then the race-losing one, assuming that its push is not rejected as a non-fast-forward in the first place, will check out the new master . The checkout process itself holds a lock on the index file while the work-tree is updated, since the index is cacheing data from the work-tree.

So this assumes that the post-receive hook is on the server

Now we can see what "set up correctly" means: the post-receive hook must run on the (single) server that you have designated as the server.

If there is more than one server—for instance, if you use GitHub as the central repository, but the web server is elsewhere—then you are stuck: there is no way to know, on the web server, that the GitHub server was just updated.

Fortunately, GitHub provides "notification" hooks: you can set things up so that your web server knows to fetch from the GitHub server, once it receives such a notification. However, this requires a completely different setup on the web server, not a post-receve hook.