Updating My Website With Git and iOS

This website is powered by Kirby, a file-based CMS, running on a VPS with Digital Ocean. Instead of the site’s content being stored in a database, Kirby uses Markdown-formatted plain text files, so publishing a new blog post is as simple as adding a new text file to the content directory, after which it’s immediately available on the site.

For a few years now, I’ve had Dropbox running on my server to sync the site’s content directory so that I can easily publish or edit content on any device1 without needing to directly upload any files to the server. This has been especially useful in the past twelve months as the iPad became my primary computing device, so I was able to use any Dropbox-enabled iOS writing app, such as 1Writer, to write and publish blog posts. As soon as I finished a new post, I’d remove the draft tag and it would appear on the site.

I’ve never been fully happy with this workflow, despite it working successfully, because it doesn’t easily fit in with how I develop and version control the site’s source code, and content2, with Git. But thanks to the iOS Git client Working Copy, however, I’ve been able to use Git on my iPad and iPhone in the same way I would on my Mac and even deploy those changes to my server.

A clone of my site's repository in Working Copy

Working Copy is a fully featured Git client that brings with it a range of supported Git features and makes use of some great features of iOS that are often overlooked, such as Document Provider3.

Just like on my Mac, I’ve cloned my site’s repository (named, unimaginatively, jordanmerrick.com) from GitHub to make whatever changes or additions I want (either a new blog post or a tweak to the source code), locally. Once I’m done, I commit and push the changes back to the default remote origin repository on GitHub.

Automatic Deployment From iOS

Since Working Copy supports many of Git’s standard features, I’ve been able to take advantage of another common use for Git – automatic website deployment. This has eliminated my need for Dropbox syncing and even publishing site changes via SFTP from my Mac, replacing them both with a process that pushes changes to a secondary remote repository – my server.

To set this up, I followed Digital Ocean’s guide on setting up automatic deployment with Git. In a nutshell, I’ve configured a remote repository located on my server as a secondary remote for jordanmerrick.com within Working Copy, and on my Mac, named live.

On the server, a Git Hook4 listens for any changes that are received, which happens when a push has been completed to the live remote, and runs script that updates the files in /var/www/html. Basically, as soon as I push any changes to live, either from my Mac or iOS devices, the site is automatically updated.

Thanks to Working Copy and automatic deployment, whether I’m on my iPad, iPhone or Mac, I perform the same steps to make changes to my website and deploy them:

  1. Fetch and pull any changes from the remote origin repository (GitHub).
  2. Make any necessary changes, such as adding a new blog post or editing the site’s layout.
  3. Commit and push the changes back to origin.
  4. Push the changes to live (my server) so the site is then automatically updated using a Git Hook.

Finally, Working Copy has a comprehensive URL scheme and supports x-callback-url, making it possible to create powerful workflows and actions with apps like Workflow and Drafts. The URL scheme is extremely powerful and not only can new files be created or edited, but commits and push actions can be performed as well. I plan on looking into the URL scheme in more detail soon, as I’d like to have a workflow that takes a blog post, creates the necessary text file, then commits and pushes the changes.

  1. To protect my personal Dropbox account, I set up a second Dropbox account specifically for the server and shared the content folder between my personal account and the server’s account. Should my server or its Dropbox account be, somehow, compromised, my personal Dropbox data is never at risk. 

  2. Including a site’s content in version control, in many cases, isn’t really necessary (or possible, if your content is stored in a database). Since my site’s content is a directory full of plain text files, it’s worthwhile to include it. 

  3. Using an app that properly supports Document Picker, such as Textastic, Working Copy appears as a Document Provider and files can be directly opened without needing to be copied around iOS. 

  4. Git Hooks are custom scripts that run depending on certain criteria. In this case, the post-receive hook runs a script once a push has been completed that replaces the server’s public HTML files with an updated version. 

Leave a Reply

Your email address will not be published. Required fields are marked *