Git branching strategy for a newly lean team

Question

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?

Answer 1

Besides GitFlow nozari mentions, there's also GitHub Flow. The place I work at used that as a basis (master is always stable, develop in feature branches, pull request with review before merging). We deploy less often then GitHub does, so on master we use annotated tags to track releases and lightweight tags point to whatever commit is in staging/production right now. This is managed by the capistrano-deploytags Ruby gem.

Unless I'm reading your problem incorrectly, you could achieve the same with this strategy with less complexity in all those branches.