Are DVCS like Git inappropriate for teams using continuous integration?

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).

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.