August 20, 2008
I consider this the golden rule of source control:
Check in early, check in often.
Developers who work for long periods -- and by long I mean more than a day -- without checking anything into source control are setting themselves up for some serious integration headaches down the line. Damon Poole concurs:
Developers often put off checking in. They put it off because they don't want to affect other people too early and they don't want to get blamed for breaking the build. But this leads to other problems such as losing work or not being able to go back to previous versions.
My rule of thumb is "check-in early and often", but with the caveat that you have access to private versioning. If a check-in is immediately visible to other users, then you run the risk of introducing immature changes and/or breaking the build.
I'd much rather have small fragments checked in periodically than to go long periods with no idea whatsoever what my coworkers are writing. As far as I'm concerned, if the code isn't checked into source control, it doesn't exist. I suppose this is yet another form of Don't Go Dark; the code is invisible until it exists in the repository in some form.
I'm not proposing developers check in broken code -- but I also argue that there's a big difference between broken code and incomplete code. Isn't it possible, perhaps even desirable, to write your code and structure your source control tree in such a way that you can check your code in periodically as you're building it? I'd much rather have empty stubs and basic API skeletons in place than nothing at all. I can integrate my code against stubs. I can do code review on stubs. I can even help you build out the stubs!
But when there's nothing in source control for days or weeks, and then a giant dollop of code is suddenly dropped on the team's doorstep -- none of that is possible.
Developers that wouldn't even consider adopting the old-school waterfall method of software development somehow have no problem adopting essentially the very same model when it comes to their source control habits.
Perhaps what we need is a model of software accretion. Start with a tiny fragment of code that does almost nothing. Look on the bright side -- code that does nothing can't have many bugs! Test it, and check it in. Add one more small feature. Test that feature, and check it in. Add another small feature. Test that, and check it in. Daily. Hourly, even. You always have functional software. It may not do much, but it runs. And with every checkin it becomes infinitesimally more functional.
If you learn to check in early and check in often, you'll have ample time for feedback, integration, and review along the way. And who knows -- you might even manage to accrete that pearl of final code that you were looking for, too.
Posted by Jeff Atwood
Important: There's one catch in that you must make sure you visit the account every 14 days - otherwise the account is marked 'Inactive' and the files are deleted!!!
Yup - I'm working on a project just now where one of the developers had source code checked out for more than a week and then, instead of checking in, pulled an old copy down from the server and that was all the work gone!!! Which meant we missed a test cycle and had to wait for the next one. This was also on a laptop, so if they had lost that then, again, it would all be gone. You can never check code in too often, in my opinion.
I go on the approach of Always check in the code, even if it doesn't work or isn't finished, you'll still be able to change it later!. Then there's no chance of loosing the code. When it's all done and everyone's happy with their piece of code and each piece has passed unit testing, then we create a version and release it for business test. Then you only every roll-back to working versions - by working versions, I mean versions that actually compile and can be installed - obviously they may have bugs, but they'll be fixed the next time we do a version.
@BugFree: Unfortunately it seems the 'bleeding obvious' is not always so obvious to some people.
@Paul Souders: The philosophy in the UNIX world may well be small modules loosely coupled, but a pearl is small modules extremely tightly bound up. A string of pearls, though...
A pearl is also pretty much an oyster's allergic reaction to a piece of grit, so your analogy's mileage may vary :)
Right, because every service and application can easily be broken down into a set of tiny features that don't interact and are all individually simple to test.
I often wonder what world some developers live in, to be unable to imagine a large module that's impractical to partition and even more impractical to unit-test. It's just not that easy... some things aren't functional at all until they're mostly done.
Even though this seems like common sense, I unfortunately run into developers all the time that don't check in at least once before going home at the end of the day. So although many of us take this stuff for granted, and may even want to give Jeff a hard time about this blog post, there are many people reading this that probably think it is okay to go days without checking their code in.
Whatever value lies in this approach does not lie in particular tooling. Git certainly does not solve the problem; as long as the changes aren't merged, you can still get conflicts or worse yet, difficult to track down semantic errors. If you can use this way of working (and sometimes it's just not possible), then you have to actually share the changes with the other people working on the same codebase - nothing less actually achieves much. It's not so much your committing, as it is their checking out of your changes (or a testers checking out of your changes) that provides the safety net.
Cant agree more, that's my rule of thumb too, besides if you don't do that you almost automatically forget to check-in something
Thanks and good luck! this is really an excellent software for for automating and streamlining check in and other team based activities.