I’ve interviewed and met a lot of computer science students. Many do not know what a source control system is, and those that do haven’t used them effectively. Read on to hear my thoughts on how to use source control.
Pick Something Modern
CVS just doesn’t cut it anymore. I personally use Git, and I really like it. Combine it with git-flow and you’ve got a very nice solution. I can’t speak to Mercurial, Bazaar, etc. because I have not used them. Whatever you pick, it should allow for a distributed type of version control. No matter how small your organization is now, it may grow. Having gone through source control system changes, I know first-hand that it can be very painful. It’s best to start with what you think you’ll need five years from now. Besides, most version control systems out there are free anyway.
Have a Branch for Releases
Ah, the release branch. This is probably the most important branch from a customer support perspective. If you tag your releases and make sure the release branch only has release tags in it (a release tag is a snapshot of the code at a point when you thought it was in a releasable state, and you actually released it where a customer or customers would see it), then you always know what features are in what version of your application. Better yet, you can know exactly which commits are in each release of your application. In my system (the git-flow system), master is the name of the release branch.
Have a Branch for Completed Features
In the git-flow system, all development work is merged into a branch called develop. All feature branches are started from the latest version of develop. You should always be able to compile, syntax check, code-review, etc. against develop. Nothing should be added to it until it is ready for prime-time. By keeping a clean, ready to do version of develop, you can create new feature branches off of it any time without worrying about some things being broken or starting a feature with failing tests. Morale can fall fast if developers have to fix unrelated tests before they can start working on the feature they are assigned.
Complete Features in Their Own Branches
Features start from the develop branch. Always. If you are keeping develop at a ready to release state, this should be a trivial concern. A feature branch is started from develop, the feature is completed, and then the code is merged back into develop once the tests have passed and amy organization specific requirements (code review, etc) are completed. This will help keep the develop branch clean, and help keep developers from trampling each other’s work. I say help, because even in this model it’s possible. Communication is very critical to any source control process, including this one.
Complete Bugfixes in Their Own Branches
Bugfixes start from the master branch. Why? Well, because bugs are typically reported from the field (customers!). Once a hotfix branch is complete, it should be merged into the master branch (for release to production) and develop (so future feature branches are free of this bug).
The Git-Flow Workflow Model (Visualized)
I’ve used this system (Git & Git-Flow) to work on or oversee over twenty-five applications. Issues have been minor, and are usually the result of developer error. If you aren’t using a system like this, it can take some time to get everyone onboard and used to using it. My experience is, two to four months. The more you hammer these points home to your teams, the faster adoption can happen. You’ll know you’re there when you hear one developer ask another why they are working directly on the develop branch and explain why it’s bad.
If CS students began to work this way in college, they would have a good head start on what most software development companies are trying to do. If you can’t keep your code organized, how can you keep your application organized?