Too many times now have I seen a fear of committing code, with many developers waiting until they are absolutely certain their code is damn near perfect before hitting commit. I blame the terminology, commit sounds so final and carrying reputation consequences. That's why I prefer to call them checkpoints:
A checkpoint is a point in time that you can return to - no matter what happens:
- Your hard drive fails
- You find yourself needing to backtrack
- You take a holiday
- You lose a 'life'
The more checkpoints you have, the more choice you're giving yourself in the future to return to.
That's why I advocate of checking your code in early and often. Don't worry if it's a work in progress, there are missing tests, it's not perfect. Check it in!
Of course I'm not advocating checking in crap, meaning there has to be rules:
- It should compile
- All tests pass
- You keep it on your own branch
- You include any new code since the last commit
- A commit message is nice (although not mandatory for every commit)
These are just common courtesy to your follow developers meaning they'll be able to pick up from where you left off for whatever reason.
Using source control like this keeps your code safe, provides an audit trail, and allows others to see your work.
Therefore I urge you commit often after all it's your branch.