How often should we commit? Is git commit quantification of quality?
Commit Often, Commit Early
"Commits to your goal..No matter what!"
This line of quote may fool you to think that this post is all about commits. Yes, it is! But it is not commits in real life, commitments to wake up early, commitments to be nice, to do that, not to do that, to become .... what and what not.
This post is all about git commit. I repeat .. git commit.
Before, I jump on to my views on git commit, First let's know what git commit is. In a layman's term, git commit is recording the changes you have made on a version of a file/s you have.
Let's say, you have a text file readme.txt. In this file you write instructions to do something interesting - Like Changing Socks. Say you decided to remove a line from that file which bugs you. Right now you know why you have removed the file but the future yourself may not know about this change. So the very concept of git commit is to record this changes.
Have you ever see people rock climbing or experienced it by yourself. What we do in rock climbing ? We climb up a little distance, and then we put anchor in the rock, we again climb up a little distance then again we put anchor in the rock. By any misfortune you ever fall, the last anchor you planted in the rock secures you. You will never fall more than a few meteres. This is all with git, you code a little bit, and whenever you find a somehow stable position, you commit. By any badluck you fail here, you can always go back to the commit and you know it is a stable position.
So,
Whenever
- You integrate an incipient feature, COMMIT.
- You integrated a working method, commit.
- You fine-tuned a broken link, commit.
- You fxed a typo, commit.
- You fine-tuned an erroneous indentation, COMMIT.
There is no wrong in commiting diminutively minuscule changes, as long as they are relevant and make sense.
The best answer to question "How often should you commit?" would be "More often than you are doing now". Commit every change that you don't think breaks something, But otherwise, the smaller the changes you commit the better.
What if we commit infrequently?
Let us consider, we have Programmer A and Programmer B. Programmer A commits conventionally but our Programmer B commits "Once in a Blue Moon". When programmer A find some issue, 'A' immediately fixed it, commit it. But, when B find some issue, he will make some changes to fine-tune the issue but he will not commit it immediately. He then does different things maybe integrating another file, abstracting the file, he may integrate incipient feature, may abstract some old feature and only then commit.
Now let's revise what we have got. From 'A' we have got a clear log of what the issue was and where the changes occurred. But, from our wholesale trader i.e 'B', we have a sizably voluminous pile of changes, we don't know what the issue was, where the changes occurred. Genuinely, 'B' messed everything. So, there is no point in committing things in a wholesale.
But, Note that commits are not a quantification of quality, In fact, they are not a quantification of quantity additionally. A number of commits you have made, Lines of Code ++, Lines of Code --, issue solved, ticket closed, a bug found, they are not a quantification of quality or even quantity.
So, Commit every change that you think WORTH COMMITING. Commit as long as you don't get repine about doing so. Commit if you don't optate to get screwed up.
Quick Tip
Git messages are generally written in present tense emphasizing what the commit does. For example: Fixes wrong indentation in index.html.
References
Heavily inspired from QA forums. Cannot find the links now to post it here.