“Check in all code as often as you can, especially when you leave for the day, whether it’s ready or not.”
Here’s a riddle for you: what’s worse than not using a version control system? Answer: using it incorrectly. The way you use version control can affect productivity, product stability, quality, and schedules. In particular, something as simple as how often you check in your code makes a big difference.
You should check in code as soon as you are done with a task; you don’t want to hold that code on your computer for an extended period of time.
What good is your code if you have not made it available for others to integrate and use? You need to get it out to start getting feedback.4 Obviously, checking in code weekly or monthly is not desirable—you’re not using version control for its intended purpose. You might hear various excuses for such sloppy habits. Maybe folks say that developers are working off-site or offshore and the access to the version control system is very slow. This is an example of environmental viscosity—it’s easier to do the wrong thing than to do the right thing. Clearly that’s a simple technical problem that needs to be addressed.
On the other hand, how about checking in the code before you are done with the task? Perhaps you are working on some critical code, and you want to go home and work on it after dinner. The easiest way to get to this code at home is to check it into version control system at work and check it out when you get home.
But if you check in code you are still working on, you’re putting the code into the repository in an unworkable state. It might have compilation errors, or the changes you have made might not be compatible with the rest of the code in the system. Now you’re affecting other developers as soon as they fetch the latest copy of the code.
Normally, you check in a group of files that relate to a specific task or a bug you have fixed. You check them all in together, along with a
4Plus, you don’t want to keep the only copy of the code on a hard drive backed only by a “ninety-day limited warranty” for very long.
SHARECODE ONLYWHENREADY 163
Safe, But Not Checked In
If you need to transfer or save source code that isn’t quite done yet, you have a couple of options:
Use remote access. Instead of checking in half-baked code to take it home, leave the code at work, and use remote access to work on it.
Take it with you. Copy the code to a USB stick, CD, or DVD to work on off-site.
Use a docking laptop. If this is a persistent problem, perhaps you could use a laptop with a docking station; that way you could have the code with you anywhere.
Use version control features. Microsoft Visual Team System 2005 has a “shelving” feature, some products have the notion of promoting code to be available to others inde- pendent of checking it in to the system, and in CVS and Subversion you can set up developer branches for code that isn’t ready for the main line (see [TH03] and [Mas05]).
meaningful log message that will let folks in the future figure out what files changed and, more important, why. This kind of atomic commit will also help should you need to roll back the change.
Make sure all your unit tests still pass before checking in the code. One easy way for you to make sure the code in the control system is healthy is to use continuous integration.
Share code only when ready. Never check in code that’s not ready for others. Deliberately checking in code that doesn’t compile or pass its unit tests should be considered an act of criminal project negligence.
What It Feels Like
You feel the team sitting there at the other end of the version control system. You know that as soon you check in, the world has it.
Report erratum
SHARECODE ONLYWHENREADY 164
Keeping Your Balance
• Some version control systems distinguish between “checked-in”
and “publicly available.” In that case, you can perform temporary check-ins (while traveling between home and work, for example) without incurring the wrath of your teammates.
• Some people like to require code reviews before allowing code to be checked in. That’s fine, as long as it doesn’t unduly delay the check-in. If any part of your process is slowing you down, revise your process.
• You still need to check in code frequently. Don’t use “it’s not ready”
as an excuse to avoid checking in code.
REVIEWCODE 165