
  Possible Duplicate:
  Version control for independent developers?  




I've heard statements to the effect of: "Well it's just me working on this project so I don't need to put it under source control" as well as, "There is no need to work version controlled on this project, it's so small".

It is my opinion that no matter how small the project is, so long as it's adding value to the client (and they are paying for it too) that we, the developer(s), should version control it; especially since its company policy.

Am I insane or does my standpoint make sense.

Question: Should development work always be version controlled?

Oh wow, yes.

I use both SVN and Git and I cannot tell you how many times they've saved my ass. More Git than SVN, but let's not start flamewars here. This is on projects I work on by myself, as well as projects I work on with other people. No excuse not to, really.

As a human, I'm basically entitled to do stupid shit all the time. By using version control, I can merrily carry on my way doing awesome things and committing at intervals where it makes sense. When I do something incredibly stupid then I can simply rollback my changes to the last point where I committed. Even with Git, I can roll back specific chunks of changes to a file rather than the whole file.

My version-control (ab?)using work flow, as a Rails developer (and yes, I know you use C#, same flow applies. Just sub my git commands for your tfs commands), goes like this for a brand new project:


Grab a new feature off Pivotal Tracker and figure out what the hell it's supposed to do. Also known as Client-to-English translation.

Create a brand new directory for the project and then immediately:
git init
git add .
git commit -m "Initial setup for [project]"
git remote add origin git@github.com:radar/project.git
git push origin master



I now have a Git repository ready for me to commit to, with a master branch. This master branch should always remain "pure". The tests should always be 100%-passing-no-excuses-or-somebody's-going-to-get-fired-slash-very-badly-injured-did-I-mention-no-excuses on this branch. If the feature is adequately complex enough (taking me longer than an hour or two or if the change is going to be more than a single, sensible commit) I will create my own branch using git checkout -b [feature-name], if not I will work on master.

In this branch, I can do whatever the hell I like. master's still going to be "pure" and I can effectively trash the place and then git checkout . to get it all back. It's in this branch that I develop the new feature, making incremental, sensible commits along the way. Made a page where a user can fill in a form and then something to handle that form? That's a commit. Added a new function to a class and tested it? New commit. I may be inclined to push this branch up somewhere so other people can work with me on it, in which case I would git push origin [feature-name] and then they could clone the repository and git checkout origin/[feature-name] -b [feature-name] to get my changes and we could work together on it. 

When I'm done with the feature, I run the tests on the [feature-name] branch. Then, I can go back into the master branch, make sure everything's still "pure" by running the tests, and then git merge [feature-name] to merge the branch into master. Then I run the tests again to make sure it's still "pure" (remember, no excuses) and finally I push my changes to the master branch on GitHub.

Rinse, repeat.

Without version control, I would be utterly lost. I would do stupid shit and then spend quite a lot of time manually rolling it back and not being sure if I've got it all or not. Version control is a great tool to prevent stupidity (as is testing, but that's a tangential topic) and I really, really strongly encourage it. 

No excuses.
