Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I work in a shop that lives by its CI process. We have traditionally used SVN and are considering moving to git (want to leverage its ease of branching, stashing, etc). Thinking in terms that a distributed source control system, by its very nature, seems to put the need for a central repository as a secondary concern, does git create any challenges for a CI process? As long as the developer performs a "commit" then "push", does the concept of a central repo as I would have known it with SVN still exist, making CI builds just a different config (pull from git rather than svn)?

Any cultural issues (developers pushing to main repo less often and instead only committing locally perhaps)?

Would love to hear success/failure stories from a group that uses CI with git.

share|improve this question
up vote 4 down vote accepted

It doesn't add any more complexity that couldn't be considered opportunity. While you can use Git in a completely decoupled, decentralized fashion, many projects usually settle on one (or several) 'blessed' repositories, and these are the repositories that the CI server should be building.

You might have 'blessed' repositories for the main (as in the one you ship from) repository, as well as some for branches that eventually make their way to the end of the line. You can use your CI server to do what it does best, detect toxic revisions at any link in that chain.

So in many ways, it's better, because you catch stuff before it gets put into the central trunk and out in the wild to blow up gloriously. Still, the art really isn't the CI process, it's establishing a Git workflow that permits you to place CI builds at key places.

I use Hudson with both Git and Mercurial projects, sharing a similar workflow. Git is actually the easier of the two, as branches in Git are a bit easier to manage. Typically, we have a small team with one lead, the team lead gets requests to pull to a blessed branch repository. If CI checks look good there, the team lead sends a pull request to the project manager, who pulls in to a -next repository. If CI builds are fine there, it eventually goes into the single (combined) release repository. So you really can run tests at almost every step of the way, or less, depending on your need.

share|improve this answer
excellent, thanks for the feedback! – jayraynet May 11 '11 at 5:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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