The Single Best Source Control Model

Some best practices are so evident that nobody seems to be bothered to write about them. Just have a glance at the software development books you have. Does any of them explain how to properly use source control system? I'm sure they don't.

However, I know first-hand that most software developers finish their studies with not an inch of knowledge regarding source control techniques. That's why managers need to be technically savvy. We have to tell them about it!

Now, it doesn't happen often that I keep silent about anything. Whatever the subject, my opinion is usually formed before I have finished thinking about it. However, with source control techniques, this is apparently not the case.

Two Great Articles
I know two very good articles on source control that every software developer on the planet should read. OK, I admit that is an opinion. But once you've read them, I'm sure you will understand why I feel that way.

Version Control for Multiple Agile Teams (Henrik Kniberg)

The Importance of Branching Models (PDF) (Chuck Walrad, Darrel Strom)

Both articles agree that there are good and bad ways to organize version control of your code. Both offer more-or-less the same advice on what the best branching model is, and I couldn't find any flaw in their reasoning. I had nothing to disagree with. (And that's a rare experience to me.)

For agile software development, a good version control model is essential!

Release Software Any Time
Agile team need to be able to release software at any time, while working on new iterations, and (usually in my case) sorting out a few bugs from the previous one. The branching model promoted by these two articles takes care of that, and much more.

I am actually surprised that source control isn't covered in the books on agile development methods. But then again, maybe this is the only subject on which Schwaber, Beck, Cockburn, Poppendieck and De Luca all agree as well.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Blog Post #100: Your Feedback Please!
Book Review: Agile Project Management with Scrum
How to Create a Pre-Project Document

  • Blog Post #100: Your Feedback Please!
  • How to Select a Fine Technical Manager
Related Posts
free book
“How to Change the World”
  • Danielle

    A friend pointed out your blog post to me and I have to say, check out this page from Accurev for some great information on best practices for Agile and “source control” – source control being much more than source control with Accurev. Please let me know if you find something interesting here to blog about.
    This is a great blog to follow on Agile, software configuration management and source control too!

  • Jack Repenning

    From the Kniberg article, the single most important remark:
    On the whole, many teams seem to over-rate the benefits of implementing many stories concurrently. It gives a nice feeling of speed but can be an illusion since it pushes the risky and time consuming bits to the end – merging and integrating and testing.

  • James

    One of the reasons I think at least some exposure and involvement with open source (however fleeting) is useful.
    It never occurred to me, when I started working, to not use source control, or that branching/merging and working in a distributed fashion wasn’t natural.
    Since I’d been hacking on OSS projects in high school, it just seemed like common sense to work like that.
    So, I walk into my first job, and ask about the source control server. Visual Source Safe, one step above copying files around.
    That didn’t last too long 😉
    @Jack: If your teams have the discipline to integrate early, and often, and build things in small chunks, it works quite well. Depends on the nature of the teams though, if they prefer to work in isolation until its “done”, I can imagine some significant pain merging things back.

How to Change the World - free Workout - free