git commit frequency

Question

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

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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