How often should we Commit?

Posted by Nischal Lal Shrestha on July 28, 2017

Commit Often, Commit Early

"Commits to your goal..No matter what!"

Just a line of quote may lead you to think that this post is all about commits in real life, commitments to do this, to do that, to become .. whatever?

Hell No!!, This post is 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.

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.

    Butt, 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.