A couple of weeks ago we shut down the Crowd Favorite office for a day and a half to do a migration from SVN to Git. This was not a small undertaking. We had nearly five years of code in a single SVN repository that was then broken out into literally hundreds of Git repositories.

The main reason for the change is to be able to support a branch driven development workflow (using Git Flow). We were already using this for newer projects (including some of our Open Source WordPress plugins that we host on GitHub), and we were seeing lots of areas where this approach would be a big improvement to our SVN workflows. We think it will especially pay dividends for our ongoing retainer clients.

With our ongoing clients we are commonly engaged in building new features and functionality while also needing to be able to make smaller changes (hotfixes) that are pushed up immediately. With Git it is easy for us to maintain development of more involved functionality in feature branches and still being able to push up quick changes as needed.

We’ve been following a modular development methodology for years, so we have a large number of libraries, plugins, etc. that are shared across various projects. Converting these from SVN externals to Git submodules was a good bit of busy work, but more importantly it required everyone to get comfortable with the difference between SVN externals and Git submodules. The biggest changes are that the submodules default to a detached head and don’t auto-update to the latest code in a branch. These are generally positives, but require changes to how you think about things. More on this in a future post.

We are using GitHub to host our Open Source projects, but we choose to host our own Git server for our private repositories. We are using Gitolite for repository management, GitPHP to provide a hackable web interface and we’re planning to use Gerrit for code reviews.

One of the other challenges was setting up a repository structure that we were happy with for our WordPress sites. We settled on the following:

/index.php
/local-config.php (unversioned – has machine specific settings)
/wp-config.php (define WP_CONTENT_DIR and WP_CONTENT_URL here)
/wp/ (WordPress core as a shallow Git submodule or SVN checkout)
/wp-content/ (plugins, themes, etc.)

This works quite nicely for simple and painless WordPress core upgrades, local development environments, and scriptable deployments. With a standardized structure, we’re also able to create scripts to automate the creation and data seeding of local development environments. We’re still working on the local dev set-up script, but I’m really excited about it. It should make it much easier for any developer on our team to quickly spin up a project and be able to contribute to it.

Does this sound like fun? We’re hiring! Come help us define and implement best practices that make developers effective; and work on interesting and challenging projects.

This post is part of the thread: Version Control – an ongoing story on this site. View the thread timeline for more context on this post.