We’ve talked a little bit about Subversion in a previous post and we’ve also linked to GitHub in a number of our articles. Both are source code version control systems, and although we’ve used them throughout a nuber of posts, we’ve never actually defined what they are.
If you’re an experienced developer, you’ve probably been using version control systems for a long time, but if you’re a beginner that may not be the case.
If you’re doing any sort of development that is subjected to bugs and/or potential issues (read: anything that is built using code :)) and are deploying it to users, you should be using version control.
Introducing Version Control
Generally speaking, teams of people build software. This means that, at any given time, a number of people are writing code that is bringing the application to life.
Of course, this means that each member of the team has a copy of the code base on his or her local computer. Of course, changes from the developers’ machines must ultimately make it into the actual application.
And this is where version control systems come into play.
When teams of people build software, there are a number of unintended effects – perhaps one developer’s feature breaks the latest version of the code, or maybe another developer’s latest implementation doesn’t properly fulfill a project requirement, and so on.
In this case, it’s important to be able to track application changes, file history, who committed what code, and the state of the project at any given time. This is exactly what version control gets you.
It allows for teams to continuously evaluate the state of their application, if it’s ready for deployment, if a rollback should occur, or how close a the team is to project completion.
In Part 2, we’ll take a look at how version control systems work and a few options that are available.
If you’re new to version control, it can sometimes be a little overwhelming – it’s a decent amount to learn for the sake of managing code. Questions?
David Alan Hjelle says
Looking forward to this series! One of the big complaints from very small teams or single developers not using a VCS seems to be that “It’s a whole lot more complicated than just having a shared code directory and making sure we don’t edit the same files.” And, to some degree, that’s true: you don’t have to learn any new tools, though the conflicts can be a pain if you aren’t careful.
So: why do you think someone should be using a VCS? (I have my own thoughts, here, but I’d like to hear others!)
Tom says
The choices for team-based projects are clear, but if you’re working on a single project I argue that the advantages of using source control are snapshots, a breadcrumb trail of the history of the project, and the ability to track bugs, issues, and – assuming that you have tests – to address when certain ones break.