Why one would commit changes to version control every three minutes?

Question

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?

Answer 1

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.

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

Answer 3

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.

Answer 4

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.

Answer 5

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.