Working with Sitecore, Part Twelve: Source Control Workflow

Wednesday, March 27, 2013 @ 04:02

By: Josh Jenkins, Lead Consultant

OK, so this doesn't really directly relate to Sitecore but it's part of my process and I feel it's worth mentioning. This post is about Mercurial!

A lot has been written about Mercurial, so much in fact that I'm going to just touch on the basics.

For those of you who don't know know Mercurial is a free, distributed source control management tool. It efficiently handles projects of any size and offers an easy and intuitive interface.

Like I said there are a lot of great resources out there and I highly recommend checking them out, some of my go to resources are:

This post is really more about my workflow which is pretty much based off of Steve Losh's post on the Stable & Default Workflow. As Steve states Mercurial itself uses this workflow for development and honestly I set it up exactly as described in his post.
  • Default is the development branch where new features are added
  • Stable is where bug fixes are added, as well as improvements that don't pertain to new feature

That means when someone ask you to fix a bug you don't work in the Default branch, you update to Stable fix the bug, test it, push it, then merge it back into Default. Stable is always clean. I see a lot of devs who want to make the fix in Default and then merge Default into Stable. This is bad. This introduces instability. We don't do this.

A typical day works out something like this:
  • I do whatever work I need to do, bugfix, new feature, whatever...
  • I pull incoming changes for the branch I am working on: hg pull -u
  • I merge the changes into my local repo: hg merge
  • I resolve any conflicts if there are any
  • I add any files I need to: hg add *
  • I commit my work: hg commit -m "What I did"
  • I push my changeset out

Wash, rinse, and repeat. Using the principles of Continual Integration I make my changesets small and push multiple times a day. I encourage, well force... devs on my team to pick off one story/bug/feature/etc... at a time, do the work and merge it back in before moving on to the next task. It keeps things moving well enough at least on the teams I've worked with, which have been between 2-8 developers on small to medium sized projects.