Git Archive for WordPress Themes

Hey there! I'm currently working on a CLI tool to deploy WordPress apps to DigitalOcean. Check it out! It's free and open source.

Quick tip! If you’re using Git when developing WordPress themes and would like to create a clean “export” of the theme that would be installable from the WordPress admin interface and accepted to the themes directory, you can use the git archive┬ácommand for that with some special arguments:

git archive --format zip --output /path/to/ --prefix=themename/ master

This will create a zip file called with a themename directory inside from the master branch of the Git repository. This means that when the theme is unarchived either by WordPress or manually, you won’t end up with a themename-1.1 directory.

About the author

Konstantin Kovshenin

WordPress Core Contributor, ex-Automattician, public speaker and consultant, enjoying life in Moscow. I blog about tech, WordPress and DevOps.


  • Hi Konstantin,

    Nice tip. We're using GitHub for themes and plugins. If you're using GitHub for WordPress development too we've made a GitHub updater that will pull the latest version of your branch to your WordPress install and drop it in place. It's over here

    We haven't released it yet, it's certainly a beta, but it's made updating our live sites much quicker – they can now pull the latest themes and plugins straight off the GitHub master branches.

    Would be interested to know your thoughts.



    • James, that's very clever indeed. Yes we use Github for our products and I also love the idea of branching. I took a peek at the source but haven't tried it, pretty sure it works though ;) We use tags to distinguish stable version from development branches and the master branch but it's not crucial.

      However, what is crucial is that we use private Github repositories for commercial themes and plugins, thus they're not accessible by anybody outside the company. I'm thinking of setting up an update server just like the updates API and have a Git hook feed the server with the latest stable tag. Or have our update server authenticate and ask Github for the latest tag, in which case your code could certainly help.

      Also, you said “updating our live sites”, we don’t have many sites to update, mostly demos of the themes we’re selling and guess what we’re using to update the themes there?

      git checkout 1.2

      And voila. I know it's "cowboyee" but it's something that works and lets us revert back to 1.1 if something went wrong. The other (probably best) way is deploying with Capistrano :)

      Thanks for your comment and hope mine made sense :)

    • Hi Konstantin,

      Yes – that reply made sense. I remember now that you have shell access to your sites, which is something we often live without on shared and cloud hosting (which is what we spoke about on a post on backing up the WP install).

      We've added private repository access to the updater so that it can work with our private client repos too. It uses the GitHub user's API which is nice.

      After we've tested it on a few more hosting platforms I think we'll blog about it and set it free :D


    • James, oh that's fair enough and awesome. Please do keep me posted and since this sounds like an interesting tool, I'll try and get you covered on ;)

    • Cheers for the pre-test feedback. Hopefully if you get a chance to try it out you could give some feedback on the GitHub or to my mail – that would be great. I'll drop you a line from our twitter when we release it fully.

      Have a good one!

  • The same for Mercurial users :)

    hg archive –prefix=themename/ –rev=REV /path/to/

    With -r you can set the revision, or don’t include it at all for using the working version.

    The file type is assumed from the DEST file extension, the options are:

    “tar” tar archive, uncompressed
    “tbz2” tar archive, compressed using bzip2
    “tgz” tar archive, compressed using gzip
    “uzip” zip archive, uncompressed
    “zip” zip archive, compressed using deflate