Version Control Done Right
Version Control Done Right
Learn more from this brief introduction about why version control is so important and how it used to be managed before automation.
Join the DZone community and get the full member experience.Join For Free
New Report Reveals Open Source Risk Is Still a Mystery to Many. Read more.
Branches are an important, but either misused or underused, part of any version control system. They provide a way to maintain a snapshot of a code base at a point in time that you can roll back to whenever needed. This is especially useful when regression bugs pop up. But they also have a significant downside — merging. Merging is the worst. By which I mean it's time consuming, difficult, and expensive. The key to implementing a manageable and useful branching strategy is to understand why you want to branch, when you need to merge, and to minimize the cost of your strategy, any developer friction, while maximizing the benefits you're looking for.
You can also use tagging or snapshotting — in fact, I usually recommend a combination of the both branching and tagging. I'll suggest teams use a snapshot or a tag to mark a specific release, with a related branch that can be used for maintenance releases (some version control systems allow you to create a branch from a tag, in which case you don't need to create a maintenance branch until you really need it).
Appropriate configuration management design is boring, but surprisingly important. Maintaining a software product, even if you're the only one working on it, is difficult to do with the right tools, let alone by hand. And today, with easy to use offerings from GitHub and Bitbucket, those tools are more available than ever, and they're frequently free (or really cheap). Prior to offerings like this, we needed to stand up our own version control systems by hand, usually things like CVS, and then Subversion. They worked just fine, but you still needed to manage them. Not anymore — and believe me, that's a good thing.
Remember, what you're actually doing is designing processes, not tools. The tools are things you use in the processes you design to get the outcome you're looking for. And just like designing anything else, there's good ways to do it and bad ways to do it. Good ways allow you to get your outcomes with minimal friction — things work, they're as easy as the can be, and they don't get in your way. Bad ways either don't work, are more complex than needed, or get in the way of the things you're trying to do.
In this group of articles, we're going to use Git as our example system for designing these things, but really you could use any version control system, for the most part. Let's get started!
Opinions expressed by DZone contributors are their own.