2

Isn't daily commits (committing all changes before going home) an XP practice?

What are the benefits of following this?

What are the risks of not following this?

Improve this question
2
  • 2
    Instead of committing per day I like to commit functional complete changes. Preferably small functions to keep impact low on related processes like code review, testing and merging by others.
    – Kwebble
    Commented Mar 8, 2013 at 22:51
  • 2
    No, "daily commits" is not an XP practice.
    – Martin Wickman
    Commented Mar 9, 2013 at 7:47

5 Answers 5

Reset to default
17

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.

Improve this answer
11
  • 10
    I'm always amazed that there are people that don't commit multiple times per day. Making small changes and merging repeatedly is the best way to avoid horrible debugging sessions in the future.
    – Brian Knoblauch
    Commented Mar 8, 2013 at 19:50
  • 2
    When practicing Atomic Coding and BDD, and working efficiently in a productive language, I don't find it uncommon to commit multiple times per minute. It wouldn't even occur to me to commit only once per day.
    – Jörg W Mittag
    Commented Mar 8, 2013 at 20:34
  • 3
    Committing before going home is a legacy behavior that was a result of SCM systems locking files. So, if you called in sick the next day, no one could use your file. Fortunately, we no longer live like animals. I would much rather work with small, simple changes to the source code that can be easily evaluated rather than 25 file , 1400 line change sets (commits) that no one can follow.
    – ipaul
    Commented Mar 9, 2013 at 5:18
  • 1
    "Make commits small and easy to review.: Small commits are not always easier to review than committing all the changes together, sometimes you need to see the whole story in order to understand how the individual changes are related to each other.
    – Giorgio
    Commented Mar 9, 2013 at 10:50
  • 1
    @Giorgio Sometimes commits naturally need to be large. For example a variable name search and replace. But if you've got a careful code review process in place, the first thing that happens when you shove a large commit at people is that they tell you to break it up into smaller commits before showing it to them.
    – btilly
    Commented Mar 9, 2013 at 16:24
3

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.
Improve this answer
3

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.

Improve this answer
4
  • I know people that do interface changes friday afternoon in the middleware, then leave for 3 weeks holiday. You bet what happens next monday: desperate users calling help desk, nobody knows what's happening, ....
    – Ingo
    Commented Mar 8, 2013 at 23:22
  • I agree with this sentiment. Time of day should have nothing to do with when you commit your code. You commit whenever you have added a working subset of code, and you want to save your progress and move on. If that happens to be at the end of the day, so be it, but you should have been committing your code throughout the day to begin with.
    – Eric King
    Commented Mar 9, 2013 at 5:09
  • Well said, I've always taken the philosophy of daily commits as meaning "don't work all day on something without at least one commit", not as "commit right before you down tools at the end of the day".
    – Carson63000
    Commented Mar 9, 2013 at 5:37
  • @Ingo: "You bet what happens next monday: desperate users calling help desk, ..." How can this happen? Do you deploy a freshly committed version to production without any testing? With appropriate code review, branches and CI this should not be a problem.
    – sleske
    Commented Mar 11, 2013 at 12:58
3

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.
Improve this answer
1
  • 2
    Benefit: you make your changes available to other developers
    – Kwebble
    Commented Mar 8, 2013 at 22:40
2

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.