Hmm my opinion, as a parable:
One of the major mistakes of IBM was to charge microsoft per LoC so they purposely added more code than necessary damaging the product in the longterm because it made sense from an economic perspective.
So back to the nature of the problem: Some people like to commit 100 small commits others just 2 meaningful commits.
Some people measure by applied change others measure by the absence of needed change.
So what is more valuable? Someone who does a lot hence can make a lot of mistakes? or someone who thinks and does as little as possible hence has a lower probability to produce bugs?
Even there we have different dimensions between lazy, incompetent, motivation, thoughtful .... so the idea shouldn't be an arbitrary number as a measure of quality or output.
Personally I would go for 1 commit of the current state of the day. If I spent 8 hours planning and drawing there will be no commit.
The idea of measuring commits is like the idea of measuring LoC it measures throughput in a quantitative way.
That's all you get / do with this
Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!
💬 Ask programming questions without being judged
🧠 Stay in the loop and grow your knowledge
🍕 More than 500K developers share programming wisdom here
❤️ Support the growing dev community!
We could also measure how many packets of Cheetos they ate as a kid, it's equally useful as a metric. Particularly when you consider some people seem to commit every line of code separately; while others rebase and squash a week's work into one.
I suggest you simply make logically-separate, succinctly-commented commits that help you get your work done and it should work out fine :)
In my opinion, the amount of commits does not mean anything and only wastes time when done incorrectly.
You want to create a meaningful git history, where you can easily go back and revert a specific feature that might have introduced a bug or issue that you want to undo.
This is a very hard task to accomplish when you fill your git history with spam commits just for the sake of producing commits.
I don't think doing multiple commits a day in GitHub should be a goal. It's just not the focus - otherwise you would write one line of code and then commit to GitHub saying "added line 234 in AnyOneFile.code".
In addition, aren't you wasting your time committing your code to GitHub 20 times a day, if you could update everything just 5 times a day.
Your goal should be adding a major feature in so and so days. For example, one of my goals was to implement match-making for my Android board game "Surakarta" in one day.
Sorry if my post was a bit discouraging.
I think the number of commits is not a good measure for a developer. Source code should have committed when it should have a requirement to commit since lots of commits make repository more complex. According to my opinion, you should do a commit for a code change with a well-defined set of requirement. If you need to save your change on a git branch, instead of a commit, amend it to the previous commit. Another thing is that commit is not the only dimension to measure the productivity of a developer. It also includes code reviews and issue reporting.