What is the cleanest branching strategy to use when creating reusable artifacts?

Question

If I have 3 environments : integration, staging, and production, what is the cleanest branching strategy to use, assuming I want to reuse my deployed artifact?

For example, should feature branches be merged into master and then built to be deployed to integration? Or is there another strategy that allows you to have 1-to-1 mapping between your releases and SCM?

Some more details ... Say I merge into master, and that kicks off a build, which produces an artifact. That same artifact should be deployed to all environments to ensure consistency. Is it best to start that process with integration? In that case, there is a rather large potential window where untested code is in master before verification can occur. Is it better to use an integration branch, deploy that to integration, then merge to master and use that artifact for staging and production? Or does that just increase the need for duplicate testing?

Answer 1

The simplest/cleanest branch strategy is IMHO the one used in continuous deployment: a single/main integration branch which is also your release branch. From What is Your Branching Model?:

Commits can go all the way to production from one trunk/master, if the automated build says the commit was good. It’s the turbo-switch for TBD, where no humans can hold up a release by taking their sweet time testing it and giving a belated seal of approval. Github, Etsy, Netflix (and many more startups) are all here.

You'll effectively use the CI build artifacts from that main branch across all environments. Well, as long they build and pass the respective QA verifications, obviously.

Note: there are no feature branches in this strategy, at least not long-lived ones - in order to eliminate/minimize the integration delays and costs. Practically you can eliminate branch merges from your development.