Version Control: Entire site or just pieces?

I’ve been using git to track changes in the plugins and themes I’ve developed for different sites. Each plugin or theme has their own repository in whichever local install of WordPress I happen to be using for that project. This works fine when I’m just working on one solitary plugin or theme.

But when I have a local version of an entire site which is a collection of different plugins, themes, WordPress core, etc. Should I be keeping that entire directory under version control?

Read More

Is there a best practice to always have a collection of repositories for each theme/plugin, or for each client site to have one monolithic repository that includes all the code used in the project (including the latest copy of WordPress via svn.)

Related posts

Leave a Reply

3 comments

  1. There’s no set best practice, as each model fits different work processes.

    One Repository

    If you’re only managing a single site with a single set of plugins/themes then a single repository makes sense. Or if you’re managing multiple sites that use the same set of plugins/themes.

    Multiple Repositories

    This is my personal preference.

    Keep WordPress core under SVN version control so it tracks the official repository. Then check out/clone each plugin or theme as needed separately.

    I often clone all of my plugins via Git to a special folder on my machine, then symlink each to folders in /wp-content. Not the prettiest way to do it, but I can use one local copy of a plugin in multiple, independent test installations of WordPress.

  2. Use one repository for your site, and then add each theme/plugin repository as git submodules.

    This way you have one repo that represents an entire site, but you do not have code duplication.

    The same is true of SVN, use svn externals in place of git submodules.

    As EAMann mentioned, it is a good idea to use symlinks/junctions on a central folder containing your repos if you have a lot of instances of them.

  3. Best practice of life is avoiding duplication of useless data.

    In common

    For each project, based on any public third-party code you can save only part, which convert this project into solution from default vanilla distro. In my case, I’ll store only my changes to upstream core (if they exist) and own added code