[Update 2012.03.07] - I forgot to mention that fork’ing, rebase’ing, and some other basic features make it easier to be a write-only developer. One of the critical paths is when you update/merge your local repo with the remote base while you’re actively developing. Yes, there are some procedures to minimize the risk like commit then pull and merge, however, this does not isolate your changes nicely. A subject for a completely different conversation is “one code repo” like Google or “one code repo per project”?I have participated in a number of strategies for commit’ing code to a repository. Each strategy has side effects, unintended consequences, and unimaginable consequences. The common strategies are: commit often commit after a complete thought commit daily regardless of state commit after a complete featureWhen beginning a new project I like to start with a fresh directory/folder; layout the first set of project files which could be created by a generator like Rails, Django or an IDE; and then I like to take a commit snapshot. This gives me a solid “initial commit/import” so that any false commits from this point can always be rolled back to right here.Commit’ing often protects the project from hardware and human error and when you are in a team setting where the scope is narrow or with a high level of mutual dependency then commit’ing often seems like a good idea. The problem here is that rolling back commits can be a very painful procedure. Specially when commits are things like “updated a comment”. It’s just not on-par.Commit’ing after a complete thought seems like another good idea. For me, however, a complete thought can take days to commit. Typically there is a POC (proof of concept) and then a few cycles of refinement. I hate to commit the POC only because peer review can be brutal when not taken in context.Commit’ing daily regardless of state is probably the worst idea ever. This is guaranteed to break the build. In the book Debugging The Development Process the author talks about not commit’ing unless it builds locally without errors and passes the regression testcases. PragProg has a book, long since forgotten, where they first introduced me to CI (continuous integration). Someone hooked up multicolor lava lamps to the CI machine and any time the build broke the red light would be on. And the person who commit’ed the broken code became the librarian.Finally, commit’ing after a complete feature. This is not unlike commit’ing after each thought, however, in this case you have a better connection between the feature request, aka story, (I hate that usage), and the actual code. I don’t really like the idea of a project request having n number of pull requests. I remember a teammate/librarian; she was constantly pulling requests and merging back into trunk. It was simply painful to watch,.As an aside; commit’ing for the sake of code reviews or metrics is a mistake. Programmers with eventually find a way to game the system; whatever system you setup. LOC (lines of code) has long since been debunked.So what is the best practice? It’s probably somewhere in between. It depends on the team and their capabilities, the scope of the project or projects. The important thing, however, is to be flexible.