Jeremy’s First Law of Continuous Integration

If you check in very often and/or first, you can make merge conflicts be someone else’s problem

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • JC Grubbs

    Oh so true…and a daily favorite of mine πŸ˜‰ I haven’t seen a merge tool in months…good luck sucka’s

  • Jeremy Gray

    @David – then I think you missed my points about keeping things “tempered with good practices, a retained requirement to meet all pre-commit criteria” and competing “in a healthy way”. Obviously, even then this isn’t blindly applicable to all personality types and/or in all environments, but I would hope that I need not make that explicit given that ANYTHING to do with ANY software development process is highly dependent on the environment under consideration.

    On a random but related note, anyone working in an environment where they think that this _wouldn’t_ work should probably take a long, hard look at the people and processes around them. I suspect you’d find that there are much larger problems lurking. As should seem obvious in hindsight, the possibility of healthy competition in your environment is almost entirely dependent on the existing health of your environment.

  • Max Pool

    ROFL –

    Max’s First Rule of CI Club…Don’t Talk About Merging…Second rule of CI Club – DON’T TALK ABOUT MERGING!

  • David Starr


    Why is the elephant pink?

    Seriously, though. I don’t know that I believe in “healthy competition” within a single team anymore. It may be fun for 2 guys to play with each other over a particular issue like this, but an ongoing behavior of “gotcha” is detrimental to the overall team, in my experience.

  • alberto

    And that is one big pink elephant in the room no one seems to talk about in the

  • Jeremy Gray

    “But, if you are the one doing merge conflict resolution, it means that your code can always trump the conflicting code”

    Yes, but it also means that you are the one having to deal with a larger delta.

    In the last few environments in which I’ve worked, we’ve even gone as far as to describe committing first as “winning”. The desire to “win” by committing first needs to be tempered with good practices, a retained requirement to meet all pre-commit criteria, etc., of course, but I have found that encouraging people to “win” creates a healthy feeling of competition where people end up competing to see who can do better work decomposition (so they can commit sooner) which often effectively translates into competing to see who can produce better-designed code. It really can be a “win” for everyone, if guided with a degree of care to keep things balanced (I want everyone to compete in a healthy way, not to rush, for example.)

  • Mark Nijhof

    Hehe just revert the other ones changes, if it happens you are not fast enough πŸ˜‰

  • Jeremy D. Miller


    I don’t know about you, but when I’m merging conflicts, all I want is for the dadgum thing to work so I can check in

  • Tom

    But, if you are the one doing merge conflict resolution, it means that your code can always trump the conflicting code

  • Jimmy Bogard

    That’s why when anyone ever asks, “is anyone integrating”, my answer is always, “yes, me”

  • Paul Davis

    Jeremy, you’ve stolen my quote πŸ˜‰

    Actually, whenever I’m asked how do I deal with merge conflicts, the answer is always, “checkin before the other guy”.