Over the last several years, I’ve played around and used several Source Control systems. Among the Perforce, GIT, Subversion and a few others. I have to say I’m very happy with GIT thus far. Despite the complaints of some, GIT is an excellent system and has saved me from source code hell a few times.
You can find more about git here:
http://git-scm.com/

The tutorials are quite good and can get you up and running quickly.

Once you’ve created the repository, go ahead and created an annotated tag with, for example the name v0.1.
After this, running the “git describe” command will provide you with incremental versioning, which is very much needed when you’re reporting bugs on a
particular commit. Just try giving your colleagues the SHA1 of the particular commits when they ask you the version in which the bug was found. I suspect they’ll be none too pleased, though you might get to figure out who knows what SHA1 is 😀

This automatic versioning is also useful when using a Continuous Integration server such as Hudson, Jenkins, etc.

Have you ever found a software bug and then went back to add printf and other debugging capabilities later?
I think we’ve all done that. However, that approach is way too late. There is one true maxim in software:

Your software has bugs

Given this, the best approach is likely to add debugging capabilities first, then add the actual code later. There are plenty of advantages for this:
1) You’re much more likely to add the debugging prints if you have easy to use debugging functions
2) Issues will happen almost immediately once you start writing code. You will get to writing working code faster if you have a consistent debug method

In Windows/Linux, printf and similar functions are one way to go. Please note that using a good debugger in itself is critical, however, it’s sometimes easier to see
a chain of events happening when it prints. Make sure to use the line number Macros in C whenever possible since they’ll let you know immediately where the error is.

In embedded systems this becomes a bit more tricky. Embedded debuggers provide the ability to use printf across JTAG and this is quite good sometimes, but it might be better to use a separate UART connection. Another good option is that if your system has any kind of flash storage (such as SD card) then print the log information there. This is useful in the long term when you’re not paying attention and everything comes crashing down. You can then have a look and get a better idea of what is going on.