Question

Consider the following situation:

I have a git repository foo.git that contains code of a javascript project. In this repository there is a branch production that contains the state of the code as served by a web-server which fetches the code from /var/www/foo. This repository is the master repository for the project. Everybody pushes and pulls from/to it.

Is it possible to have /var/www/foo updated to a checkout of production whenever someobody pushes to that particular branch? You may assume that the git daemon (or the user git which is the user all people log in to to connect via SSH) is entitled to write to said directory.

Answer 1

You have to create a bare repository on the server with git init --bare.
Then use a post-receive hook to trigger your deploy.
How you deploy is up to you.

My Deployment Strategy

I usually place a deploy director, somewhere logical.
Then each checkout, I unpack the latest branch to deploy/COMMIT_ID where COMMIT_ID is the hash of the latest push. Once the checkout is complete, you can re-point a symlink to the latest deployment directory.

My usual directory structure:

deploy.git/
deploy/
    a7922231/
    b2f0a2af/
    latest -> b2f0a2af 

Unpacking the Update

Rather than use a git-checkout, I usually use git-archive to unpack a branch into a directory.

# Assuming current directory is deploy.git
HEAD=`cat refs/heads/master`
mkdir -p ../deploy/${HEAD}
git archive master | tar -x -C ../deploy/${HEAD}

Your web-server can point to deploy/latest, updates will be more-or-less atomic.

I use this often in production, and has a few benefits over unpacking over the same directory.

1. rollbacks are easy
2. you can do post-unpack procedures, like compile or install dependencies without interrupting the current deployment

Tips

1. each update, append to a deploy log that says when updates occurred, and what their hash ids are. This makes rollbacks much easier.