Question

I was just checking in my code and realized that I’m have no idea what criteria my code should ideally meet to perform a check in.

Yesterday I checked in after having it my project checked out for a week. Today I checked in again after making little updates. Sometimes I like to keep the code I’m working on checked out until it can get through a little bit of testing.

My boss usually gripes about people keeping code checked out over the weekend or vacations, so I try to avoid that (if for no other reason than because I forget what I’m working on).

Should I be concerned about hitting a critical mass of code or not being able to find bugs because there’s too much code to search though?

Answer 1

Check ins should be made often.

A check in should be

• Atomic. Contain all needed changes but no more. Which also means that
• whitespace changes go on their own commit.
• change only one functionality. This might change several functions, but it shouldn’t change functionality in several ways and / or places.
• commented. A check in comment should enable you to quickly find a commit, even if it’s 2 years old and you aren’t working on that particular source (or even project) anymore.
• working. Only commit if the code actually builds and does what it claims to do.

If you need your personal playground for committing consider a working branch or mirroring the repository with something like git svn. Remember to merge changes done in an atomic way as much as possible. This might be more work but it immediately pays off if you need to figure a commit that changed or possibly broke something.