Has this branching strategy sense in a web development ecosystem?

i don't know if this question is stack-overflow related or it should be posted on another stack-exchange platform, but anyway..

The problem is a new branching system that we have in mind to adopt in near future. At work we develop primarly web applications (ecommerce, cms, classified, special purpose) and some websites in php and our vcs is svn.

This is the new model that we want to adopt:

Trunk: always development

Staging (branch): a branch created to test new features on remote ambient (the same system that live has, really the same server..)

Live (branch): branch for live.

Other branch开发者_高级运维es to develop concurrent features.

Now, the idea is to bugfix live and then push back changes to trunk. Develop features directly on trunk or into another branches then merge to trunk.

Push trunk into staging to get ready for new features that will go live really soon; and then? how we can get that staging into the live branch? We have to pass from trunk?

Now the strategy is:

Trunk : it's the live version

Branch for each feature

Live bugfix done to trunk then pushed to branches

Staging is a working copy that switchs for a branch at the end of the development of the feature, before the merge back into trunk.

But this method has some drawbacks:

• always switching..

• no possibility to test two concurrent branches

What do you think about the new strategy?

We have branches/feature for large feature development, releases/x.y for live releases (essentially as tags, but occasionally because more than one release is live concurrently) and trunk is used as a staging for a release. Bug fixes are made on trunk and selectively pushed to any branches or release builds as necessary.

Trunk is usually run on our staging servers (different hardware, internal-only access) and once it's stable we'll tag it as a new release and deploy it to the live hardware.

You don't say what source control system you use, but most of them have a suggested strategy (http://svnbook.red-bean.com/en/1.0/ch05s04.html#svn-ch-5-sect-6.1) for example.