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?
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:
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.
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.
1- Commits should be frequent; committing code to the remote repository (not just locally) should be done frequently so that the code is backed up just in case it is somehow lost; this happens more frequently than you'd expect so, pushing your changes by end of day is a must to avoid potential rework and to ensure the remote repository is always up to date.
2- Commits should be granular and therefore should not include too many changes to the code base. Commits with too many changes are harder to revert and cannot be used as a reference from a "history" perspective as commit messages would have to be too long in order to cover the full scope.
3- Commits should have a proper title; title should start with a capital letter and should not end in a period. Generally, titles should be short and to the point.
4- Commit descriptions are optional but are nice to have.
I commit pretty far apart. git isn't meant to "backup" your code, you should be using tarballs or dropbox or something to ensure you don't lose code.
If you don't commit very often you can better tell exactly what should go in what commit and it gives you a smoother history than 50 commits with
"oops", "damn", "forgot that file"
you can rebase, but if you never stage/commit in the first place, theres no need to undo your work
