Who needs a version control system?

I’ve recently had some discussions about teams and individual developers and the use of version control.  I’ve (unfortunately) learned that:

1. Not all teams see the value of version control
2. Even if version control is used, teams stop at basic check-in/commit functionality
3. Single-person development “teams” don’t think that version control applies to them since they are not sharing their code with anyone

So what is the value that version control brings to you and your team and why should you bother with it?

If you look at your folder structure and it looks a little bit like this:

Or, if you are using a Shared folder on the network to get collaborate with the rest of your team…
You may need to re-evaluate how you are doing things.  Sure, it may work *sometimes* , but there are some major flaws with those strategies.

Some reasons to consider version control – even if you are a single developer:

• Undo: You started working on some changes and you realized that you need to go back to where you were?  You are one click away from doing so.  Whether you want to undo changes to a single file or multiple files, it is very easy to do.
• Compare: Do you want to know what changes were made since you started working on the latest set of changes?  Again, a single command will get you there.
• Change tracking: Sometimes I don’t ever remember what I did 2 hours ago, let alone what I did a month or a year ago.  Version control lets you see every change that has been done to your code files, not just by you but by anyone in your team.
• Back to the Future: Do you ever want to go back in time and see how your application behaved before or after a certain change was made?  Again, it’s an easy operation without having to dig through backups of the system. You can simply go back to a previous version based on a specific date, and there you have it.  And once you are done, you can go right back to the present.
• Collaboration: Do you want to share your code with other developers?  Don’t sent the files through email, file share, Dropbox, One Drive, IM, thumbdrive!!  Check-in, commit, push, or whatever your version control system calls it, and have the other developer retrieve your changes from source control.
• Branching/Merging: This one seems to scare a few people, but really, branching is your friend.  If you need to work on a piece of functionality while the rest of the team works on something else, and then in the future, you want to integrate your changes with theirs, this is the way to go. Or if you simply want to try something out, but you are not really sure if it will be the final solution, create a branch, if you are happy with it, then merge it, otherwise keep going, or toss it.

I know this is second-nature for a lot of developers, so this blog may not apply to you.  If you see someone not using version control, then stop and ask “Why?”.  And I don’t care what system you use.  I love Git and I love Team Foundation Version Control, so if you use those, great.  If you use Mercurial, Subversion, Perforce, VSS, or any others, then that’s great too.  Use something, find the system that works for you and your team and be successful with it.  You should never be at risk of losing a day or weeks of work because they didn’t use proper version control strategies.  If you are in college and you’ve never used a version control system because the professor never asked you to, then start using it. It is very likely that your first job out of college will use it, and you’ll already be ahead of the game if you know how to use it properly.