Macro vs Micro commits

[Gregg Bolinger]

I've had a few conversations over the past several days regarding macro and micro commits. I've not found any conclusive evidence that one is really better than the other. I'm wondering what others prefer and why.

[Eric Nielsen]

I think (not knowing your definition of micro vs macro) that I'm in the micro camp. I try to commit after

a new unit test and code changes to make it pass

most of the time this touches 2-4 files at most

and then a second commit after any refactoring needed to clean it up.... this one often can touch more files, but still is normally quite localized.

As I tend to also have acceptance tests wrapping my suite and driving the smaller TDD cycles, I struggle with whether or not to commit the acceptance test, in its failing state, while I work through the smaller unit tests needed to get it passing. Lately I've been doing
a) if the test doesn't require extending the testing domain specific language, I don't commit it until it passes
b) if I had to extend the DSL, then I'll extend/refactor the existing acceptance tests and commit that change, but still often leave out the failing test case until it bases. If I know I'm handing off the development of the feature covered by the acceptance test case to another developer, we've decided that its OK to have a failing acceptance test in those instances...

[Ilja Preuss]

Micro commits. Reason: divide and conquer!

[Jesper de Jong]

Where do you draw the boundary between a micro-commit and a macro-commit?

When I'm working on code, I usually commit my changes at the end of each work day. I have to take care that whatever I commit doesn't break the build. We have an automated nightly build and unit test.

[Tim Holloway]

I do micro commits as a CYA in case my development system gets trashed (i. e., as a backup) and if I'm doing some major stuff that might end up in the bin if it doesn't pan out. While I prefer that these commits be capable of being compiled and tested, the main thing is that it's backed up.

Macro commits for me are milestones and I tag them. A macro commit is a major fallback point, a release, or a system version that is potentially the launch point for a new development effort. I expect that macro commits will build and run.

In the real world, it's not uncommon for me to have to append notes on bugs, quirks, and FYI's to a macro commit after the committed version has been exercised, and that's normally a micro commit.

[Gregg Bolinger]

Great info guys. Up to this point I am more of a macro or "feature complete" committer. I have no specific reason for doing so. It's just kind of how I was taught along the way. But lately I've been trying to micro commit more to see how it fits in with my dev style.

[Ernest Friedman-Hill]

I'm also a microcommitter, but doing that requires working in a certain way. Some people like to make a big mess, and then put things back together; during the "big mess" phase, those folks shouldn't be commmitting. But if you work in an incremental TDD style, taking small steps, then I agree perfectly with Eric's description of when to check in.

Now, another question for people: I've never worked on a nontrivial project that used Cruise Control or similar; all of my large projects have used nightly builds. If you're using Cruise Control, do you hesitate to check in, even a little bit? If you know that doing a commit is going to fire off a build and mail everybody test results, are you more likely to, say, wait until after you've done all your refactoring for a task before checking in?

[Ulf Dittmer]

If you know that doing a commit is going to fire off a build and mail everybody test results, are you more likely to, say, wait until after you've done all your refactoring for a task before checking in?

Well, the setup we've used was to do a build once an hour (so you generally have a chance to fix something if you notice it pretty quickly), and to email only those people who've checked in since the last good build (plus the PMs).

But yes, in a team you'd check in once a functionality is supposed to be working. Not necessarily tested to the developer's full satisfaction yet, but smoke tested so it's known not to break anything else in a big way.

[Jeanne Boyarsky]

I'm a micro-committer. I like having a clear rollback point (the last point things were in a decent state.)

On our team, we don't have a "don't break the build" policy. We have a "try not to break the build and if you do fix it ASAP" policy. This works out well. The build doesn't break often, but when it does we are informed of something important. For a bad compile or unit test failure, it's that we forgot to check in a file. We also have a whole host of configuration validations, static analysis, code coverage, etc the build does. These are the things that tend to "break." It's a good thing that the build finds these so I try to work on the build finding things having positive connotations.

[Tim Holloway]

Guilty. I'm a "make a big mess" person. However, as I said, I micro-commit because it's a good backup system. Where I've worked lately, desktop systems didn't get backed up and I got burned to the tune of 5 weeks labor once when the drive blew out.

However, I do want my main trunk to be buildable, so I normally do that stuff in a branch. For environments where that's too much trouble, I tag the milestones.

[Ilja Preuss]

Tim, I suppose you are the only one working on that code, aren't you?

[Ilja Preuss]

Originally posted by Ernest Friedman-Hill:

Now, another question for people: I've never worked on a nontrivial project that used Cruise Control or similar; all of my large projects have used nightly builds. If you're using Cruise Control, do you hesitate to check in, even a little bit? If you know that doing a commit is going to fire off a build and mail everybody test results, are you more likely to, say, wait until after you've done all your refactoring for a task before checking in?

Nearly a million lines of code, distributed over around 200 interdependent modules. The continuous build only builds the modules with changes, and all directly or indirectly depending on the changed ones. If you change a leaf module, a build might take as short as two minutes. So, checking in often typically reduces the time per build. Good thing, that.

We also have a "don't break the build" policy. In fact, for some months now we apply "stop the line" to the continuous build.

We also have two nightly builds: one full build that builds and tests all modules (and currently takes roughly two hours), and one that creates the installer(s).

[Tim Holloway]

Originally posted by Ilja Preuss:
Tim, I suppose you are the only one working on that code, aren't you?

I regret to say that usually I end up with top-to-bottom responsibility for whatever system I work on, no matter how complex. Occasionally I'll get temporary use of a flunky, but when that happens, either the flunky ups and goes off to become a missionary in Moscow or the whole department gets canned for reasons having nothing to do with how well the project's going. Story of my life.

I did work on one project where I was supposed to lift off the lower 3 (+/-) layers of a product and replace them with a demoware simulator. That effort took about 2 months and was done entirely on a branch.