This was always going to be a tough week from a reflection perspective. Not because the topic, version control, was particularly difficult, far from it in fact. The main challenge for me, personally, was always going to be about showing evidence of learning.
I’m not the world’s expert in version control but I have used it on a daily basis for almost 25 years. Originally starting with tools such as MKS Source Integrity and Microsoft’s Visual Source Safe in the early days, I eventually moved on to SVN, Perforce and Git in more recent years. I also introduced version control to two companies I worked for and rolled out the change from SVN to Git (BitBucket) with my current employer.
One big positive from this week was having to research branching strategies again. This isn’t something I’ve done in quite some time and there was no surprise that the Internet is full of articles on the subject. It was good to rediscover an old favourite, in which the notion that “the use or misuse of branching and merging can make or break a parallel software development project” , is as true today as it was back in the 90’s. Perhaps more so. Appleton et al. introduce us to a large variety of different strategies for managing source branches as well as considering risk tolerance.
This last point is extremely important and something I feel is often overlooked when setting up a version control system. With almost every tool I’ve ever used creating a branch is very easy because that’s what they’re designed to do. However, we must remember that “branches have to be merged back together, and many teams spend an inordinate amount of time coping with their tangled thicket” . A good branching strategy, frequent catch-ups and a disciplined approach can help minimise merge conflicts although they can never be eradicated completely.
My preferred branching strategy for some time now has been Master Code Line, exactly the same as we used at Symbian Software for several reasons I wrote about on this post: Master Code Line Strategy for Version Control. Very simply, it is a hybrid of Feature/Task branching and the Release branching as described in . Re-appraising it to see if it was still the right choice for me on the course or whether there is something better out there drew a blank. I do wonder if I’ve become so familiar and accustomed to this system that I’ve become blinkered. Is this an issue? Perhaps, but the counter argument to that is why change it if it works so well for me?
Maybe it’s because I use it so frequently or because I’ve come from a strong software development background but I was slightly surprised to discover a few of my colleagues had used a version control system before. For this group I am more than willing to help out and share my knowledge and experience if they run into problems. Where a few had asked for advice in the discussion forum this week I shared a few tips and ideas. I believe it was received well as I had a lovely comment from one individual, Matt Wilson: “Thats great advice, thanks Gavin. I am about to start using this with my groups now that we no longer use Unity Colab. Your rules may be on my wall in a couple of weeks.“
Matt’s comment prompted me to write more detail about the system I use in this post: Master Code Line Strategy for Version Control
References
Photo by Faye Cornish on Unsplash
