Since i switched to git from svn i started make more commits every time i recompile and my tests pass i commit my work. In the end i end up committing function by function.
I also track some other projects using git like emacs,wordpress etc. I see that they do not commit that often. So i am wondering how ofthen do you commit?
As soon as tests pass, or when a unit of functionality is added/deleted/modified.
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.
It really depends.
What I do is I commit locally often, as it sounds like you're doing, but I only push my changes when I've accrued several influential ones.
This ensures that I save my work, but it also doesn't clutter the repo for other users.
Our business needs have us commit to the unstable branch when the program compiles, and commit to the stable branch when it passes unit testing and has been reviewed by the customer (while it was under the unstable branch).
What you are doing sounds about right to me. Any time you have a working setup that you want to be able to go back to if you mess something up is a good time to commit. If you have a nice setup where running regression tests is quick and easy, I could see that being fairly often. For me, I'd be lucky to make one a week.
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:
Then, the number of commits can be related to the purpose of the branch:
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.
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.
The more you commit the easier it is to find bugs with git bisect