Git is an excellent version control, but it’s more than just that.  A lot of people use it to deploy their projects as well.  Most suggestions (for example, this tutorial from Digital Ocean) around the web employ the post-commit (or other) hooks to push the code to a remote server.  While this works well, I prefer to do it differently.  I like the pull model better, where the deployment is triggered outside of git, and relies on git to fetch the code updates and run some sort of a build script, which handles database schema changes, cache resets, filesystem permissions, etc.  Such approach also allows to limit remote access to the servers (especially the production ones), and separate responsibilities of a developer and a deployer.
With the many pull, merge, fetch, and update options that git provides, it is sometimes difficult to choose what’s the right set of commands to use. Â I’ve figured it out via a rather lengthy trial-and-error process. Â But if you don’t want to go through all the pain of that, here’s a nice blog post that tells you exactly how to do that. Â I’m copy-pasting the commands here just for the future reference.
cd "${DEPLOY_TREE}"
git fetch --all
git checkout --force "${TARGET}"
# Following two lines only required if you use submodules
git submodule sync
git submodule update --init --recursive
# Follow with actual deployment steps (run fabric/capistrano/make/etc)
And I suggest you read the full article for the explanation of why this is a better way and what are some of the issues with other strategies.
