[swalsh]

If master is currently in production, a good way to do frequent deploys for code that's "not quite ready yet" is to use a feature toggle. This allows you to do partial feature deploys, but block any code paths from using it. Plus when it's time to start directing traffic towards that code path you can turn it off, if you find a bug you missed during testing.

[MatekCopatek]

This only works for isolated features. As soon as it's some kind of refactoring or a feature that affects a lot of existing code, it's not viable anymore.

[mbrock]

If you really want to, you can often find ways to do continuous integration even in such cases.

For the most brute force example, you could copy the whole program and make a runtime switch for deciding which to run.

[TheCoelacanth]

> you could copy the whole program and make a runtime switch for deciding which to run

Wouldn't that make merges even worse, not better?

[cyberpunk]

Then you should be rebasing the branch often from master so that this is less painful when the flip happens. If there is an army of devs working on the same repo then it should be communicated out really obviously. If a dev is planning on submitting code that'll be merged after the massive branch gets into master then they can just rebase from the feature branch and any conflicts should be fixed in those branches...