git commit frequency

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:

• 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.

The more you commit the easier it is to find bugs with git bisect

As soon as tests pass, or when a unit of functionality is added/deleted/modified.

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).

I commit after I add or change functionality and have a successful test. Or when I'm going to be switching from my desktop to laptop and want to pull down the code, I'll commit and push.

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