It ain't about the amount of commit, neither the amount of line changes, it's about how much of business and functional logic your commit have.

I mean, I can make 20 commits per day, but at the end, someone who reviews my history line don't get nothing from it.

Atomic commit are meant to bring the history of the development, that's something that not everyone knows how to do, how to read code and understand it. It's very easy to understand some logic if the commits give me the 'description' of a class by instance.

So, at the end, it ain't just about the amount of commit, it's about how rich they are, amount of changes, what they bring to the business logic, features (which HAVE to be atomic) ...

It's quiet difficult to see a project manager or team leader to use the real power of metrics....

As someone casually obsessed with collecting green squares on Github, I can say confidently that it's easy to double your number of contributions without creating more value.

I don't think to measure a developer based on the no. of commits is a good idea!

Thanks to all of you for the comments! Interesting perspectives, nothing discouraging I promise but I think it's quite interesting. I suppose for me, I enjoy breadcrumbing and I'll take a look more at branching as I don't think I can branch at the moment in visual studio code?

Honestly, I'd prefer to go with one or two commits a day instead of having the urge to commit each and every changes. Just relax, think, test and give final confident commit is what I do!

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.

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.

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

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.