There are a few good tutorials out there on deploying web sites using git. Many professional web developers use git to deploy updates to their test sites and customer sites. There are a few reasons why git is a fit for these tasks:

  1. Git tracks file changes and transfers only the necessary objects
  2. Git supports a number of protocols to talk to your web server, including ssh for security
  3. Git has hooks for automatically running scripts at various points to check file permissions, etc.
  4. Git can easily be configured to ignore files that do not need to be moved back and forth
  5. You’re already using git to revision and manage your code changes, so why not deploy with it?

But there are issues :

  1. Git repos do not belong on your public server, since you only want your customer to have access to the latest versions
  2. Git has a steep learning curve

My web server gives me SSH access, which is key to my deployment technique. Logging into an interactive terminal on the server, I set up a folder to hold git repos, outside of the public-facing html folder, which serves to ensure that my git is hidden from users. To put the web source files in one place and the repo in another, I need to initialize what is called a bare repository in git. This is the command :

git init –bare

And this is the resulting directory structure:

Screen Shot 2016-06-10 at 10.59.34 AM

Next, I want to create a way to push changes to my public server. Git provides hooks for automating common software development tasks. These hooks can be executed before or after several stages of git operations. The post-receive hook will be run every time code changes get pushed to the server git repo. The following two-line script will update the files under html every time I push updates to the git repo:

To make this run on the server automatically at every code check-in, I name it post-receive (no file extension), make it executable, and place it in the hooks folder in my git repo. The GIT_WORK_TREE variable assignment is needed to tell git where the live code lives, since a bare repo keeps code and history separate from each other.

On the client side, I create a git repo and assign the web server as a remote.

git init
git remote add public ssh://
git push –set-upstream public master
git push public +master:refs/head/master
git config –global push.default simple

Did the double-dash (dubdash, heh) come through up there? “–set-upstream” and “–global”. Anyway, these git settings set up the remote repo and ensure that I can push and pull code without any extra commands. I choose to name my web server public within git to reflect the fact that a push will publish the site.

From here, I can create my site code. A single push command will publish my site!

If a web site is maintained by multiple web developers on their client machines, this model works very well. Everybody pushes updates to the central git remote repo, and every user can pull recent changes using

git fetch
git merge

But, what if someone is making changes on the server directly? This is exactly what happens with WordPress. Uploaded images and plugin installations cause changes in the html folder that we want to track in our git repo. I could not find a git hook to automatically capture these changes, so I created a script on the client to automatically checkin new changes at the same time I pull them over to my client:

I run this script before running

git fetch
git merge

This all makes for a nice backup/tracking system. The WordPress posts are stored in a SQL Database, of course, so that system must be backed up separately.

Are there better tools than git for this job? Leave a comment and give me your opinion!

Leave a Reply