5

The frequency of commits depend on two factors:

  • the developer himself: some developers tend to commit often, others may spend hours without committing,

  • the current work: the same developer may have to commit very frequently when effectuating risky refactoring operations or similar tasks, and quite rarely when working on other parts of the codebase.

From what I observed, beginners tend to commit one or two times per day on average. Developers with a few years experience are probably committing once per hour on average. Committing every fifteen minutes is probably the best thing to do, but I've rarely seen this commit frequency.

Question:

I've spotted in Google Closure Library logs that it has commits nearly every three minutes from the same developer.

What are the benefits of such high frequency?

Are there consequences on the way the code is written?

Is it related to the fact that at Google, codebase is compiled and tested on servers and so one should commit the code to see if it compiles and passes all the unit and integration tests?

Improve this question
5
  • 7
    Why? To burn a hole in the source control server. – Jimmy Hoffa Aug 19 '13 at 18:57
  • 1
    That just looks like he committed a bunch of individual changes at once. Changes that were already done previously. – Robert Harvey Aug 19 '13 at 18:57
  • 2
    Because the best way to gauge developer productivity is by the number of commits. Right? – Tombatron Aug 19 '13 at 19:03
  • Are we talking about local or server commits? Source control is about creating save points. The more the better for your local repository. Pushing to the server will be less frequent due to testing and peer review. – mike30 Aug 19 '13 at 19:18
  • wow. I wish I could program that fast. – Reactgular Aug 19 '13 at 20:02
11

Depending on how much history-rewriting someone's process does, it's not always possible to tell how the commits in a DVCS were actually timed. Your linked example project uses MOE, which is an automated way to maintain a project as a combination of open and closed source. The bursts of commits likely come from use of that automated tool to scrub internal commits to make them public.

Another reason for unusual commit patterns might be a maintainer applying a bunch of patches from email or something.

I've occasionally made very close commits when I'm doing something relatively rote, like fixing a bunch of coverity issues. I've heard of TDD practitioners doing a commit between every red/green/refactor cycle. I've heard of paranoid people setting up automatic commits as a sort of autosave. I'm sure there are other reasons I'm unaware of.

Frequency of pushing is another matter entirely. The rule there is you should be confident it won't cause other people problems. I don't think you could be reasonably confident with three minutes between pushes.

Improve this answer
1
  • 2
    +1, the TDD commit-per-cycle was exactly what I was thinking when I read the question. – Doc Brown Aug 19 '13 at 19:40
2

One theory would be that each commit represents a roll back point and thus each commit is about having a copy of this version of the code base somewhere so that it can be retrieved if so desired. This is bit of a quick test cycle as both the changes and some initial tests would be done before committing.

The danger here is that if the place where these commits are being taken as the "production ready" code base, things could be an issue.

On the other hand, one could have a bunch of finished features that are to be merged separately and thus this is merging each feature so that the commit is more of a merging in the changes from somewhere else rather than new development or testing.

Improve this answer
2

When you start thinking of commits as their own individual feature, or maybe even more so in the case of a high frequency, a project state, not "saves" or "rollback points", you could often be hitting this frequency of commits during normal development, especially early on in a project.

While I guess a commit every three minutes is quite high, I do sometimes find myself committing every ten minutes or so while mentally breaking down what may be a single feature into small pieces / changesets.

Improve this answer
0

I sure hope I don't see a "recommendation" coming along that the more frequent the commits, the better.

In my opinion, each commit should leave the code base as bug-free as possible, so frequent commits are a not a good thing if bugs (i.e. incomplete features) are being knowingly put into the code base. Also, I think each commit should ideally represent one feature added (modified, removed), so that the feature can be rolled back by undoing a single change list, without at the same time undoing other features that may be desired. So that argues for commits not being too infrequent.

Of course, do I stick to this? Well, I try to, but if sometimes I don't succeed, it's not cause for dismissal :) I hope.

Improve this answer
1
0

You must make sure your code can be compiled and correctly run before you commit your code.Otherwise your co-workers's work will be interrupted by you! I think that someone commits very frequently is not so good. You should commit after you have finished and tested a function. You should commit at least once everyday.

Improve this answer
6
  • Given the size of the codebase at Google, one can hardly imagine compiling it locally. Moreover, compiling is only a part of the process, another part being running unit tests. In some cases, it would extend to running integration and system tests and deploy to staging. – Arseni Mourzenko Aug 22 '13 at 6:16
  • how does this answer the question asked? – gnat Aug 22 '13 at 9:58
  • If the compile time is very long,you can use a compile server to compile it.And many project have no unit tests. – Edward Shen Aug 22 '13 at 10:23
  • If the compile time is very very long,it is time to consider divide your program into some little program. – Edward Shen Aug 22 '13 at 10:24
  • If you commit code to result in that the sour code can not be complied,other co-work will not work!They must rollback to previous version and lost all they change,and that they can not commit code! – Edward Shen Aug 23 '13 at 1:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.