There I was the other day before going to bed scrolling through some unread articles, I tend to see the article headings and immediately send it to pocket for later reading, and found this article entitled What’s in a good Commit TL;DR the article is about what a good practice is when it comes to committing changes to a source control system, Why should you do it some way or another and the benefits for it and well it also mentions some bad scenarios when a bad approach is taken.
It kind of got me, I use Git and love it but unfortunately I do not use it on my day Job there we use TFS and always are very close of screaming in agony when using it, I don’t even let it merge the changes, I prefer to do that myself, it is safer and committing… well whatever you put there immediately affects the current code base, you can use shelvesets of course to get around this though, but they are not made for that purpose
It is very clear to me and this impacts directly on how yo get stuff done, decentralized solutions as Git provide more flexibility and also make code authoring more managable.
A good commit should define a completed and independent unit of work, you probably don’t want to have a full feature be contained in one commit, instead split that feature into independent pieces, no dependencies between them and have a respective commit for each, this allows you isolate changes and do anything with them independently without affecting other, e.g. We don’t want to rollback the code for performing a multiplication and affect the division? it does not make sense contextually.
Commit frequent, be descriptive in your messages, this will give you a better and more understandable log-like set of things you’ve been working, by doing this and defining solid boundaries between your commits will allow you the have a better control and overall view of what you are doing, you never know when you will need to go back to that log looking desperately for details :)