git commit frequency

The guideline for the Git project itself (and the Linux project, AFAIK) is one commit per "logically separate changeset".

This is a little ambiguous, but you probably don't want to commit every few days if you're working on a project constantly, and you probably don't want to commit after every function change - if you've edited several functions in several different files, you want to commit all of the related functionality together if you can and provide a useful commit message with it. All of the code modified in each commit should be related, but it can (and probably should) certainly be across several files.

What you probably want to keep in mind is in code reviews. If someone is trying to decide if they should merge your work in, it's much easier for them to process the work being introduced if you have each commit logically contained and separate from each other. That lets you (or others) cherry pick work effectively - if you have three commits with one function modified in each but they're all coupled somehow - you can't apply one without the other two without breaking the codebase - then they should probably be squashed down to one commit.

I also track some other projects using git like emacs,wordpress etc. I see that they do not commit that often.

One of the nice things about git is that you can commit as often as you like, and then when you want to do an upstream commit you can squash several related commits together into one nice clean commit using git-rebase.

In the end i end up committing function by function

Do not forget you could rather "git add" function by function, making only one commit:

• once all the functions are written or fixed for a given task
• or once you realize the current function is too large/complicated to be part of a commit any time soon: you can then commit what is currently "on stage" ("git added"), which would not include your current modifications in the working directory.

Then, the number of commits can be related to the purpose of the branch:

• local branch: go crazy, commit anytime you want
• "public" branch (one that you will push):
  • for a local repository (for selected group of people): you could regroup at least the very small "intermediate" commits
  • for a public repository (for all developers, or other projects to see): you can make an interactive rebase in order to regroup your commit by "activity" or "task" in order to make those more readable.

In short, "publication considerations" can, in a DVCS (as in "Distributed"), guide you as to make the proper number of commits for the right reasons.