Branching

[code lang=text]
Title: "Branching" on 2008-06-17 12:11:56
Categories: "General"
– "Source Control"
Originally posted at geekswithblogs.net/cskardon
[/code]

I’ve developed in 3 main situations, University, Personally and Professionally, which I believe is probably similar for most developers. I’ll freely admit that for my personal projects I’ve rarely (if ever) utilised source control solutions, even though I know that there are plenty of free solutions available. It’s just never been an issue (though I am going to rethink that).

University taught me squat all about how to use source control, I think I gained an inkling of what it was somewhere towards the end of my time there, when another project team lead mentioned to me that they were using it. I really came into the source control circle in my first professional role.

I never really realised how important source control was until then, and now I recognise proper usage of source control as a core part of the development process. I’d almost go as far as to say, the core part of the process. A crap coder can write crap code, delete good code, whatever they like, and as long as it’s source controlled – we can see what was changed, when, and importantly rollback if required.

Most devs I’ve worked with have really only ever used source control to do the usual checkin/checkout gubbins, which for 90% of the time is great. Most have heard of branching, but never actually used it, some people don’t even want to use it. It’s a big scary concept that people fear. Personally I think a lot of the fear is due to the complexity of the tools used to do the job. Well. One tool in particular. Visual SourceSafe 6 & 2005.
Branching shouldn’t be (too) scary!

Why should branching be used?

Imagine we’ve developed our program, EmailXtreme (a spiffy email app if you must know), and we’ve reached version 1, our first release! Now, to get to the first release, we’ve taken some short cuts, and some features we wanted have been cut to make the release date. But we’re in the moment, who cares?
Time passes, and development of the extra features begins.

…

More time…

OH NOES! Bug!!! One of our customers has discovered a bug in the app – and wouldn’t you know it – it’s a critical bug, EmailXtreme doesn’t actually Email (thanks testers!).

All developers get working on the fix, fortunately it’s a one liner, fixed, tested – out it goes to the customers (with apologies).

5 minutes after…

During congratulations, pizza and beer, a lone voice can be heard:

“guys, errr, what about that new feature we were working on, it’s not finished, and [cough] will break, well, everything.”

Silence. A beer can drops on the floor. Someone cries.

Quick rewind

• Release v.1 done, all good (yay).
• Dev team branch into a version 1 branch, then get developing on the trunk.
• Bug comes in.
• Bug is fixed in maintenance branch, released to the customer and finally the fix is merged into the development trunk.
• Customer and devs happy, this time they get their pizza and beer. Good job!

This is a bit of an oversimplification of how branching can work, but it’s also a good example of why branching is useful.

How?

That’s really all down to the tool you’re using. I have used sourcesafe to do this, and it pained me, and the guys I was working with. I can only really comment on one other tool – Vault, and that makes branching a doddle.

It’s worth checking your current Source Code Control (SCC) to see what you can do.