Code it

The central unit of work within any version-control system (VCS) is the check-in: committing one or more files into a repository. This records the current state of the files and preserves a record of their history. In this article, I examine the wide range of check-ins — from the minimal to the overly large — and identify the elements of a useful check-in and the costs of doing check-ins wrong.

 A check-in is an atomic operation that makes previously isolated changes visible to other users. A check-in can affect several files to keep the project consistent, just as a transaction can update multiple records and tables at once.  (To be accurate, some legacy VCSs such as CVS or Visual Source Safe only allow check-ins of single files. However, all modern VCSs support atomic commits across several files.)

Ideally, every check-in should move the project from one consistent buildable and tested state to the next. The VCS ensures that the history of these changes is stored durably.

A check-in differs from a database transaction in that it preserves the history of changes, including the author, and usually some documentation (a comment or link to a change request).

Together, all check-ins tell the story of how a project has developed. The best stories have a strong theme, a fascinating plot, a fitting structure, unforgettable characters, a well-chosen setting, and an appealing style.

A good check-in is like a sub-plot with its own theme; it makes it easy and interesting for others to read and understand the purpose and execution of each change.

more at http://www.drdobbs.com/architecture-and-design/what-makes-a-good-check-in/240168601