Daily?? If you’re following that strategy, you should commit far more often than that.

The idea is that you commit early. Commit often. Sync often. Make commits small and easy to review. Conflicts happen because 2 people are independently working on the same thing – when you work in small fast units the window to conflict becomes much smaller. And the remaining conflicts are tiny, and easy to resolve because everyone still has mental state. (As opposed to the industry standard of trying to untangle large conflicts 6 months down the line.)

The disadvantage is that you can be broken by someone else working far from you in the company. Also it makes it hard to work on branches that may or may not want to go into production. A lot of people also think that it is not a scaleable strategy – large organizations need more sophisticated practices.

I disagree with that criticism. For a reference point, at Google all changes must be peer reviewed before being committed. The average commit is less than 20 lines. Commits happen straight on the main branch. There are extensive unit tests and integration tests that automatically run before commits can finish. (With an infrastructure to make this happen acceptably fast.) The received wisdom at Google is that these practices successfully scale to Google. However if you take out any of those pieces, it wouldn’t.

I think daily commits (or more) are a good software engineering practice in general, regardless of the methodology used. Some benefits (in no particular order)

• Tracking time your commit log becomes a great source of “just what did I do on Tuesday” when filling your timesheet just before the deadline the next Monday.
• Verification/Sanity check if you’re using continuous integration, a check-in will prompt a build which gives you verification that your code (at the very least) doesn’t break the build. (Add in TDD and automated smoke tests, and you get even more validity).
• Smaller batches working in smaller daily batches, reduces cognitive load. Instead of thinking about all you have to do over this current sprint, you can focus on what you are doing today.
• Minimizing the impact of Murphy’s law I’ve had hard drives die for no apparent reason. Think of your check-in as a backup. How much work are you willing to lose when (not if) your local hardware craps out on you?

Some detriments of less frequent check ins

• Merging the longer you hold a file and the more files you hold, the more likely that your changes will conflict with another developer’s changes requiring a merge
• Going dark without check-ins, your team mates have no visibility into what you’re doing.
• The opposite all the benefits you lose all the benefits of committing daily or more frequently.

I feel obliged to point out that “committing all changes before going home” is not necessarily something that you should do. When your mind has already called it a day, you risk breaking the build by committing something and then quickly leaving the office. Consider these questions first:

• Did you compile the code?
• Did you run all the unit tests of the project to make sure everything works?
• Were you working on your very own branch instead of the master?
• Are you using a tool that shows if you forgot to include something in your commit?

Having broken the build many enough times and having seen others do it many enough times as well, I do not commit my changes before going home if I answer “no” to any of those questions. All this being said, I’m all in favor of micro commits and committing at least hourly. Just don’t commit if you’ve already put your coat on.

The concept of making daily (if not more often) commits comes out of the idea of Continuous Integration. The basic idea of CI is that developers should be integrating their changes several times a day, thus eliminating the historical norm of every one developing on their own for several weeks, then spending several months trying to integrate all of their different pieces. Most CI tools automate the process of building code changes and running suites of unit tests, so there is little burden on the developers.

With that as background, here are the direct answers to your questions.

What are the benefits of [committing all changes before going home]?

• Allows for Continuous Integration, which is a Good Thing.
• Less chance of loosing your work (if using repositories not on your machine)
• Having an easy way of rolling back something if you made a mistake
• You make changes available to other developers.

What are the risks of not [committing all changes before going home]?

• You loose something because of a hard disk crash.
• You loose something because you accidentally deleted or modified the wrong thing.
• You don’t know you have integration issues until it is really hard to solve them.
• Your code doesn’t get tested in the context of other pieces of the code.

Among many XP activities one of them is RESPECT that states:

Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers

What are the benefits of following this

• You know how much work is done & how much is left to be done.

• Other ppl have faster access to your code(less waiting time).

• Easier to spot if a programmer is doing the task correctly.

• Easier and faster code Integration.

• Run Continous Integration + unit testing.