One of the harder skills to acquire while programming in general is to split the work into small and meaningful tasks.

Too often, I have experienced this scenario: you start to fix a small issue in a file; then you see another piece of code that can be easily improved, even if it's not related to what you are working on now - you can't resist, and you fix it. At the end, and after some time, you find yourself with a ton of concurrent files and changes to commit.

At this point, things get worse, because usually programmers are lazy people, so they don't write all the important things to describe changes in the commit message. In commit messages, you start to write sentences like "Some fixes to this and that", "Removed old stuff", "Tweaks" and so on, without anything that helps other programmers to understand what you have done:

At the end, you realize your repository is only a dump, where you empty your index only now and then. I have seen some people committing only at the end of the day (and not every day), only to keep a backup of the data or because someone else needed the changes reflected on their computer.

Another side effect is that the resulting repository history becomes useless for anything other than retrieving the contents at a given point in time.

The following tips can help you turn your VCS from a backup system into a valuable tool for communication and documentation.