git post-receive hook which connects to remote via ssh and git pulls

Question

just trying to write my 1st git hook. I have a remote origin and when I push to it I would like a post-receive hook to fire which will ssh into my live server and git pull. Can this be done, and is it a good approach?

Ok i've got the hook firing and the live server is doing the git pull but it's saying its already up to date? any ideas?

Answer 1

yes, that can be done and yes, in my opinion, that is good practice. Here is our use-case: I work in a small development group that maintains a few sites for different groups of people.

Each site has several environments (beta, which is a sandbox for all developers, staging, which is where we showcase changes to the content owners before going live, training which is what our training dude use to train new content managers and live, where everyone goes to consume content).

We control deployment to all these environments via post-receive hooks based on branch names. We may have a 'hot fix' branch that doesn't get deployed anywhere, but when we merge it with, say, the 'beta' branch, it then gets auto-deployed to the beta server so we can test how our code interacts with the code of the other developers.

There are many ways you can do this, what we do is setup your ssh keys so that the git server can ssh into your web server and do a git pull. This means you gotta add the public key for git@gitserver into your git@webserver authorized_keys file and vice-versa, then, on the post-receive hook you parse out the branch and write a 'case' statement for it, like so:

    read line
    echo "$line" | . /usr/share/doc/git-core/contrib/hooks/post-receive-email
    BRANCH=`echo $line |  sed 's/.*\///g'`
    case $BRANCH in
        "beta" )
        ssh git@beta "cd /var/www/your-web-folder-here; git pull"
        ;;
    esac

Hope that helps.

Answer 2

That can certainly be done, but it isn't the best approach. When you use git pull , git will fetch and then merge into your working copy. If that merge can be guaranteed to always be a fast-forward, that may be fine, but otherwise you might end up with conflicts to resolve in the deployed code on your live server, which most likely will break it. Another problem with deploying with pull is that you can't simply move back to an earlier commit in the history, since the pull will just tell you that your branch is already up-to-date.

Furthermore, if you're pulling into a non-bare repository on your live server, you'll need to take steps to prevent data in your .git directory from being publicly accessible.

A similar but safer approach is to deploy via a hook in a bare repository on the live server which will use git checkout -f but with the working directory set to the directory that your code should be deployed to. You can find a step-by-step guide to setting up such a system here .