I work as a release engineer, and the sheer number of f*-ups that could be avoided by dev's understanding version control better is truly astonishing.
It doesn't matter very much which version control system you use (though there are a few which will give you a pounding headache) it's more important you understand a few useful processes, like merging and conflict resolution, branch strategies (e.g. feature branches, release branches, does HEAD == all source-code?, etc, and why you'd use one or the other) check-in style (e.g. larger chunk(s) with peer code-review?, frequent updates that allow you to follow your thinking at a later date?, pre-submit unit-tests?) among a few other things.
Even though not all of these things will be needed by your project(s), knowing those things in-advance are what will allow you to use a VCS effectively, even if you work alone.
I work as a release engineer, and the sheer number of f*-ups that could be avoided by dev's understanding version control better is truly astonishing.
It doesn't matter very much which version control system you use (though there are a few which will give you a pounding headache) it's more important you understand a few useful processes, like merging and conflict resolution, branch strategies (e.g. feature branches, release branches, does HEAD == all source-code?, etc, and why you'd use one or the other) check-in style (e.g. larger chunk(s) with peer code-review?, frequent updates that allow you to follow your thinking at a later date?, pre-submit unit-tests?) among a few other things.
Even though not all of these things will be needed by your project(s), knowing those things in-advance are what will allow you to use a VCS effectively, even if you work alone.