My team's development processes are based on continuous integration. The only branches we create are maintenance branches when we release, but otherwise developers are expected to commit regularly (daily if not more often) to trunk, so that everyone's work is always integrated, continually tested, and all that good stuff.

My understanding of DVCS is that it is great for branching. I worked some years ago in a team where this would have been very useful, as every bit of development was done on a branch, and only merged when complete and tested. But this was a different philosophy from continuous integration.

But it seems to me that for a team that uses continous integration, the groovy features of DVCS tools like Git would not be particularly relevant, and might even hinder the continuous integration process if merging changes requires extra steps that may be forgotten.

I'm sure there are other benefits of a DVCS (e.g. committing is very fast because it is local, presumably merging with the main branch could happen in the background while the developer carries on working).

But for this question, I'm interested in how teams which use DVCS and continous integration reconcile the two seemingly conflicting philosophies. I'm mainly interested in hearing from people who are actually doing this.

  • This is a great question. Unfortunately, most of those who've answered have mistakenly taken "Continuous Integration" to mean "running a continuous build server". What it really means in an Agile context (and what Kief is asking about), is frequently committing valuable changes to trunk which can be pushed to production. So the question is not, "Can I run Jenkins against Git?", but "What is the point of branches if what we really want to do is push changes to trunk?" Unfortunately, I don't have the CI+DVCS experience to add a more useful answer, but I plan to come back in 12 months add one. – Graham Lea Aug 2 '12 at 11:29

Actually DVCS made continuous integration much easier.

With central VCS, every developer has the rights to commit directly in trunk and therefore he can commit buggy code. CI will detect it after the fact. So it's possible to have broken trunk even with CI.

On the other hand, the basic operations in DVCS world are branching and merging. Because merging is explicit and a separate process vs. commit to the trunk, one can always check the result of a merge before it lands on the trunk. I don't have experience with Git, but developers of Bazaar VCS have used this technique successfully for at least 3.5 years with the help of PQM tool.

Basically PQM workflow looks as following: developer publishes his branch so it can be merged, then he sends a special e-mail to the PQM bot with merge instructions. When PQM receives a merge request, it makes a separate integration branch (copy of trunk), then merges the developer's branch and runs tests on the resulting code. If all tests are passed then the integration branch is pushed to trunk, otherwise the developer will receive an e-mail with the log of failing tests.

Running all tests for Bazaar project takes time, but tests are executed on demand on a separate server. Developers won't be blocked by merges and can continue to work on other tasks.

As result of PQM-based merge workflow the bzr trunk is never broken (at least as long as there are enough acceptance and regression tests).

  • Thanks bialix, tips like this are exactly what I was hoping to get from this question. – Kief Aug 5 '09 at 10:31
  • I voted your answer up, along with a couple others that offered good insight. I don't think any of the answers here (so far) are, on their own, 'the' answer to this question. – Kief Aug 23 '09 at 11:53
  • @Damien thank you very much. – bialix Oct 15 '12 at 12:31

Since all DVCSs can be used with a workflow that uses a centralized repository, there is no problem. Policy dictates that the developer must push their changes to the central repository in exactly the same way that policy dictates commits to a non-distributed VCS. The additional tools that allow the developer to edit patch sets are not a hindrance in any way, and in fact make it much easier to generate a maintainable code base.


Using a DVCS like Git doesn't prevent you from committing to a central repository regularly. However, it does mean that you can make intermediate commits locally and only push the changes to the central repository once you are done.

This way you have the benefits from source control even when you are halfway implementing a feature, without breaking the build for the other developers.

  • I think this is one of the main benefits of DVCS over centralized VC when used for continuous integration. It allows for more granular level of commits, commits that don't by themselves pass a test, but are still worthwhile to be tracked by VC. Groups of these commits then make up a complete change that together can pass testing, and is integrated via pushing to a main repo. – imagineerThat Jun 22 '15 at 3:10
  • but the thing is that you want to teach your developers to do incremental development :) with partial work that doesn't pass existing tests you're letting your team have long lived branches and then suddenly you're doing feature branching even if you don't know it yet – dragan.stepanovic May 10 '17 at 15:07

Continuous Integration tools such as Hudson have support for DVCS, so I suspect this is possible to reconcile continuous integration with distributed version control.

First, I think with DVCS using workflows such as topic branch workflow CI might be less necessary. Second, you can set up (single, central) continuous integration repository to which you push when you are ready, and hooks do CI.

Added 07-08-2009:

See for example Continuous Integration Spring Cleaning post on GitHub Blog.


Two ideas that I've found help to explains this:

  • DVCS separate commits from merges.
  • CI runs against a repository that you choose.

So the heart of the matter is how the merges are made into the repositories that you want run a CI tool against. You can choose to have just one repository when you start.

  • so long as your commits don't reduce the amount of merges you do with a centralized repo, you are still doing continuous integration. the CI should run against a repo that everyone agrees on, otherwise it's just a bunch of distributed repos that aren't integrated. – imagineerThat Jun 22 '15 at 3:16

Your Answer

