If you're using a DVCS, you should be committing very often. I commit every time my code is in a stable state, which is not related to lines of code. You want a tree of lots of small, atomic commits that makes it easy to see what you did in each. If you're trying to track down a regression you found when testing, this makes it far easier to do a binary search and track down the exact commit, because you will have fewer changes per commit. I only commit when my code compiles - my idea of "atomic" is that it compiles, passes the regression unit tests, and passes a quick integration test. Sometimes a unit test is included, and sometimes not.
When you push, you should push whole features. The rest of the world doesn't want to see your "missed checking in this file" commits every day. Git provides rebase
, which allows you to clean up your commit tree by squashing multiple commits together. The community seems to be uncertain about how much history you should commit. I'd say you should squash together the commits that don't show any of the history, like "missed file" or "dumb regression". You want to present as clean a history as you can so everyone can easily see what you did.
In a centralized version control system, you need to commit a lot more if you want to keep a good history. My recommendation is that you work on smaller features and complete them as much as you can before you commit. Your concept of "atomic" here should be a feature that works and is tested. You don't want to commit anything that break other developer's workspaces, because they will be updating often and it's a lot harder to work on independent features that overlap. You'll commit less, but those commits will usually be more meaty than your average DVCS.
You can see that the ratio of lines of code to number of commits depends on how big your features are and the workflow you use. Your workflow will be different depending on what version control system you use, so you can't generally predict what your commits will look like. Each institution has their own standard, and should determine for themselves what their workflow should ideally be.