When setting up a continous integration environment, does it always entail having the build server pull code and merge between branches?

Or is it something you NEVER want to do because you are depending on an automatic merge would usually ends up having issues (and requires manual intervention).

  • 1
    -1: Did you consider the ramifications of automatic merging?
    – Jim G.
    Aug 12, 2012 at 23:38
  • What would be the point of having branches if the CI system automatically merged them all together every time you did a check in?
    – Simon B
    Mar 24, 2016 at 9:09
  • @SimonB non-feature branches -- if you're running continuous deployment with different release channels (e.g. normal, fast) then those might be branches. For example, if the fast channel deploys nightly and the normal channel deploys weekly by merging to the nightly channel, then in theory, the build server could/would need to merge fast channel back to normal channel. What would skip the normal channel? Hotfixes and whatnot. So depending on the flow, it could be a non-issue. Aug 25, 2020 at 19:55

7 Answers 7


I've never seen a CI system doing any merging. In theory you could set it up to do that but as you mentioned the build will break if you run into any merge issues.

CI environments usually have a specific fixed branch as the "build" branch and the CI server will monitor that branch for new check-ins to fire off a new build cycle.


CircleCI, my hosted CI service can be set up to do this. Circle automatically builds all branches by default. For our own code, green builds on master are automatically merged into the production branch. Of course, only do this if you have a good test suite.

Now, that case is easy, because nobody pushes to production directly.

I think there's a lot of interesting work that can go on here. Eventually, I'd like to get all bugfix branches to auto-merge into master on green. I've been in situations where I'm working on a bug, run all the tests, then discover I need to merge with master (rather than fast-foward), and forget to run all the tests again, and end up breaking the build.

A feature I'm interested in writing is comments in the commit message that say "merge with branch X, if it's green". That way, it's never possible to have master be broken.

The other responses here don't make a lot of sense to me. Your CI system doesn't have to be dumb. It should be able to gracefully handle merge conflicts, by not merging, and informing the user. And on any "shared" branch, like master or production, merges should always be fast forwards!

  • We use circleci, any chance of publishing your merge script so we can all use it? I see it's mentioned in the docs as merge_to_master.sh and would probably be trivial to write. But hey if you got one that works saves us all time.
    – dalore
    Apr 6, 2016 at 12:34

Never do that. Automatic merge is just one reason. Even more importantly, you should be able to commit to your branch until you've finished, without fear of breaking the trunk.

However, if you're using a tool like Jenkins, you might want to add a separate automated build for your branch, so that you continue to get fast feedback on commits.

Automated merge between branches? - That is simply not a good idea.

CI is a great process and needs to be setup for comparatively big projects. However, I would never trust to automated merging. Because, it is quit common to get wrongly merged files resulting in compilation error or even worth by unintended change in coding logic.

  • never is a bit strong. I would probably say "not usually" but I think it depends. For example, if they're just deployment branches, then it's probably not that big of a deal depending on your control measures. I probably wouldn't use it for feature branches. It also depends on your source control implementation. For example, in Git, you can abort a failed merge and then fail the job, so there's no risk there. Aug 25, 2020 at 20:02

I haven't heard about any CI system that would automatically merge branches. Why? Because it is not always that easy, and even if you're using one of the most sophisticated DVCSes available out-there it is still possible that a human is required to review the code that has been changed. It is especially tricky when people have actually changed bits in the same file (i.e. same method in the class, same function).

I think automatic merging would do more harm than good. And in the end you (as a developer) don't want to waste your time on investigating issues that are not real issues, and happened just due to the fact that a piece of code was not as smart as you are, and couldn't figure out what the code after merging should look like.

  • The only times I've had to merge was when bits in the same file were changed, and only then when they were the same bits.
    – James
    Aug 9, 2012 at 20:07

Most of the answers here point out the problems of automated merging. However, we used it successfully to merge from our production branch into our test branch (hot fixes and such would automatically merge downward). And also from our test branch into our development branch (fixes to problems discovered during testing would automatically merge downward). In our case, all automated merges went away from production, giving us opportunity to review and test any merge consequences before we pushed code into production.

I'd like to say the process was perfect, but our CI system would silently fail (not perform the merge) if merge conflicts required human intervention. It would have been much better for the system to send notifications so the development team would know that merges were failing.


Merging always needs to be done manually. If you design the software and manage the development with a degree of sanity, then conflicts will arise only on very, very rare occasions, but when they do occur, they need a human to ensure that the merged result makes sense.

To get the benefit of continuous integration, developers need to merge changes and check their work into a central repo/branch on a frequent basis (every hour or so).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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