Integrating Source Control Into Your Projects
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on December 23, 2009 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
If you ask most developers about source control, they’ll agree that it’s a wise thing to use. They’ll insist that they think it’s important. But yet, why are so many companies out there still not using source control in their projects? A good number of companies that I’ve worked with failed to make use of source control, resulting in issues that would have been trivial otherwise. In this article we’ll explore ways to make sure that if your company isn’t using source control, that you can help make a change to this policy.
Source control doesn’t need to come from the top
The first oft-considered misconception is that source control must be endorsed by upper management in order for developers to use it effectively. This is 100% incorrect. There are a number of ways that developers can make use of source control, even if management fails to embrace it, or rejects it altogether.
Subversion can be set up locally on most systems; a repository can be created in a central location and, as long as you do a regular backup, your repository should be secure. Git is designed to have the repository locally by default; this makes a great source control system if you have total ownership of the project.
Bear in mind that the point of version control is two-fold: first, to make it easy to collaborate with a larger group, and second, to help version your code so that you can see changes over time and possibly roll back if there are problems. Bear in mind that in larger teams, personal repositories won’t work, but in smaller teams or in places where you own your project, you can use source control.
The person that needs convincing is probably not the upper management at all
Many of my friends work for “creative firms” that are marketing first, development last. These firms are set up to provide excellent marketing to the clients, but more or less may not care about the development team. While this is often frustrating, it can also be a blessing in some ways.
As long as the team lead can be brought on board, placing code into a repository can be easy. If the team is larger than three or four people, using Subversion or another VCS is crucial; more likely than not there will be other owners of the project and everyone will need to collaborate.
The cool thing is that most of the time upper management types don’t care how the development is done as long as it is in fact done by the developers. Thus, convincing upper management isn’t the way to accomplish the goal of implementing version control.
Version control is not a silver bullet
A few times in my career I’ve heard someone say something along the lines of “oh, if only we had been able to use version control. Then that project would have been on time.” Bzzt! Wrong.
It might seem obvious that version control is not a silver bullet but it is often treated as such. It’s such an important and ubiquitous tool that it’s easy to think that having it will solve all development problems. But it’s not a replacement for good management, good time management skills, and solid development practices.
Version control should never be cited as a way to make development faster. It doesn’t generally do this (with the exception of generally preventing developers from accidentally overwriting someone else’s work, causing duplication of efforts).
Version control is best utilized before a crisis
Again, this might seem obvious, but there’s a harsh reality amongst developers: most of the time, when they feel as though they’re not permitted to implement version control, have a tendency to say “Well, next time code gets lost, that’ll teach ’em.”
Don’t think like this! It’s just going to ultimately create more work for you, the developer, when the management wises up, realizes that they need version control, AND that they need the code rewritten that was ultimately lost. You’ll have double the work, and even though you’ll get what you want, you won’t like it.
Fight for version control consistently BEFORE a disaster. This will improve your chances of having it in place prior to some disaster striking.