5

We intend to use Mercurial for version control of our WordPress website development.

The development model in WordPress dictates that development usually occurs in a couple of sub directories off the main root for plugins and themes while the main root is subject to change via WordPress version updates and doesn't need to be version controlled.

My question is if this situation is best managed with a repository located at root with a hgignore to remove the main WordPress code from VC, with just the previously mentioned sub directories under control OR a couple of sub repositories rooted in the directories where the development occurs and a wrapper parent repository to join them together?

What are the pros and cons of each approach and the effect on deployment?

With the second approach (sub repositories) when you done the initial pull on a new server would the development directories be created in their correct position within the WordPress tree?

RSA99
  • 53
  • 3
  • 2
    Yet another possibility is considering WordPress as a dependency (which makes sense) and using something like Composer (which can then be part of the process of building on the new server, too.) Sadly, though it's heading in the right direction, it's still [somewhat fiddly](http://roots.io/using-composer-with-wordpress/). (Incidentally, the whole [Twelve Factor WordPress](http://roots.io/twelve-factor-wordpress/) post on the roots.io site is definitely worth checking out if you want to try wrestling WordPress into some form of [modern development practice](https://github.com/roots/bedrock).) – Matt Gibson Jan 03 '14 at 13:42
  • Thanks very much Matt, there are some very useful pointers there. I had discovered Mark Jaquith's WordPress Skeleton [here](https://github.com/markjaquith/WordPress-Skeleton) but, the bedrock framework seems an evolution or two on from that. – RSA99 Jan 21 '14 at 22:46

1 Answers1

1

As a general practice, I would highly recommend version controlling only the source code that you intend to maintain. Using Git, I've previously done 1 repository per theme/plugin with good results. With the exception of parent/child theme relationships, WordPress themes are more or less entirely independent of one another. Since each theme is logically separate, it also makes sense to version control it as a separate entity.

It's also very likely at some point you will want to push updates for one theme, but not others. Having separate repositories makes it easier to check-in changes for all your different themes, but only publish changes for one at a time. While you can achieve the same result using branches, if you have more than a handful of themes, it can get very complicated.

Certainly, it comes down largely to what's comfortable, but in my experience managing an install with 50+ themes, that was just what worked easiest.

  • Thanks for you response. After quite a bit more research I found the WordPress-Skeleton [here](https://github.com/markjaquith/WordPress-Skeleton) which implements a lot of the ideas you mention. I also switched to Git as that seemed more in tune with what the prime-movers in the arena of bringing WordPress development into the 21st century were using. – RSA99 Jan 21 '14 at 22:48
  • I am accepting your response as the answer but, would also refer readers to Matt Gibson's response above and the information about the WordPress bedrock framework. – RSA99 Jan 21 '14 at 22:54