At what point are you checking in too many files as a single commit? I don't know, but I think more than twenty is getting really close.

I understand we like to have things working great before checking things in. I'm really bad about creating a "defensively written" feature and not checking it in until "it's at version 1.0". Admittedly, I'm unlikely to change that real soon, as when I'm writing this way, nothing I do impacts any existing code, and I usually maintain an independent repo somewhere with my feature in a testing framework as I develop. Then you add a hook to call it somewhere in existing code, check it in, and profit.

But if you're hacking twenty or more places that other folks are hacking too, you could potentially sideline someone for hours before they can reintegrate with whatever mental model you were using to create those changes.

You have to make bite-sized changes and check them in to your team's shared repo (so team-dev, if not dev proper) as you finish each mental unit of work. It's lots easier to eat a watermelon (Why watermelon? Well, really, who wants to eat an elephant? You have to draw the line on meat somewhere, right?) when it's cut up into bite-sized chunks.

Don't dump a watermelon on your repo, man.

Labels: , ,