Branch structure for a web site

I was recently reading the TFS Branching Guide and it suggests a branch for every release. For a web site, there is only one "version" released at a time. In that case is it appropriate to have a single "Production" branch? Then, during the process of preparing for a release, 开发者_如何学Cyou merge changes from the Main branch into Production. (As opposed to the suggestion to branch each release.) If you need to do a hotfix, do it in the Production branch, then reverse integrate into Main. Doing it this way allows you to keep configuration files for Production intact in the Production branch.

p.s. I should mention that we are using a Code Promotion model.

p.p.s. Apparently what I'm talking about exists: it's called a "staging stream" in Practical Perforce

---

Usually, Production is for reflecting what is in production, that is:

• what has been pushed in the live site
• plus whatever hotfixes have been made directly in the live site

That is why, in this configuration, one Production branch is enough.

You will then need, following that logic:

• release branches where you consolidate your developments and test them before merging the current release to the Production branch. They can serve as source for a staging environment, since, as mentioned in the document you reference in your question (Practical Perfoce):

  it allows you do make extremely frequent releases without having to branch a new codeline for each release. (They’re commonly used to support web development)
  A staging stream is essentially a reusable release codeline. Each staging stream is used for a particular stage of release stabilization.

• development branches for daily devs (all of which cannot always be part of the next release), and for integrating back the hotfixes made in Prod (merge Prod to Dev).

---

I don't know if it's "appropriate" but I do something similar with Subversion...

Instead of branches/tags/trunk, I have development/test/production. New features/fixes are created in development. Once completed, they are merged to test for testing and client review (by going to the test website). Once passed QA the changes are merged to production. Hook scripts automatically update corresponding development, test, and production websites on checkin, and each "branch" has its own unique web.config file pointing to the appropriate development/test/production database.

---

What is your question? This is currently how we use TFS (which btw is ace)