We have a web app for which we have a couple of corporate customers. We have recently decided to offer it as a SaaS app and to follow the lean approach (in parallel with our corporate offering). Which means we've got experiments on the go that might not make it into production.

Before we went lean we were happy with the following branching strategy (I believe it's pretty standard):

* **master** - always stable
* **dev** - often unstable (feature branches cut off of dev for new features to
go into the next major release)
* **major\_release\_x** - live (cut off of master after dev has been merged
into master, this is where bug fixes take place and merged back into master and dev)

Now we have the following in addition to the above and it's not working all that well:

* **lean\_release\_branch** - live (cut off the major\_release\_x and contains
experiments)
* **experiment\_x** - cut off major\_release\_x (this is where we hack the
feature together and then merge it into lean\_release\_branch)

Our scenario now is that we need to release quick and often as the lean approach dictates, and when we get solid feedback on something arbitrary, then we need to productionize it and release it as soon as possible (off of the lean\_release\_branch).

The problem being we can't create a feature branch off of **dev** (as it is most likely unstable) and we can't create a feature branch off of **lean\_release\_branch** for two reasons:

1. it has been contaminated by experiment code so this change/feature won't be able to make its way back to **master**
2. the **lean\_release\_branch** always need to be ready to release, so we can't be busy doing testing and fixes on it (after merging the change/feature into it) if there's a critical issue that needs to be fixed and released

Does anyone know of a better strategy for our setup?