branching in distributed environments

I'm interested in hearing how "branching" is used in a distributed SC environment. We just started using mercurial for a team environment, and I'm hoping to learn from others expe开发者_高级运维riences - what are some good ways to 'organize' branching practices (hopefully I'll bypass the pain and time of doing it a silly way...)

From what I've read, the main trunk should contain the ongoing development code, one branch may be a 'stable' release, and others may be experiments or features... that get merged onto the trunk...

However - where it gets a bit unclear for me is on things like bug fixes and QA... most of what I've read says to branch separately for QA (merge the trunk into the branch when done, then push the branch to the trunk - This seems cumbersome, and without explanation)

I've also read that you do bug fixes in your stable branch (or release branch) and then merge with the trunk... this seems counter intuitive - as you'd possible break the 'stable' branch as you fix bugs... I'd expect the stable branch to be 'stable' and untouchable with a version #...

I can see that branching is necessary - but help me understand some practices that are out there. We're working web apps, in interpreted languages (not complied) - so it's real easy to change things,and break things.

thanks.

=======================

roger that Alex - and thanks - that makes sense -

HOWEVER I'm having a 'little' sticking point now on 'melding' the distributed model with the centralized... where a lot of the writing out there suggests having a central repository - a "watering hole" (if you will) where everyone goes to 'share' or 'pull' the latest.

so now I find the distributed model you recommend - breaks down (in my mind at least)... I don't want to keep 5+ trunks (main, hotfix, deploy/QA, develop, feature-n) and have people pull/push with each - so it seems like the developers LOCALLY will pull from Develop - and they may branch LOCALLY for features. or hot fixes... then SOME ADMINISTRATOR will merge the central DEVELOP with the CENTRAL RELEASE... the dev team 'may' have a LOCAL RELEASE BRANCH to make fixes that a QA team passes back... should they PUSH to RELEASE and let ADMIN merge with DEV? Then Pull their own changes back from the CENTRAL DEV into their local??? Or should they merge locally - and just push RELEASE back to central?

In keeping with this - I don't see a need or want for the dev team having a local copy of MAIN...

it seems like maintaining (a recommended) 3 trunk central repository (MAIN, QA, DEV) really confuses work flow of the distributed model. BUT it seems desirable to have a central MAIN - that gets pushed to your productions boxes - and a central QA that gests pushed to a QA box andt gets QA'd by a separate team..(thus can't logically be on everyone's dev box locally)

wow - managing large workflows is tangled - there MUST be some literature out there on managing this stuff - different workflow ideas etc. The TOOLS them self do NOT do a good job of describing "how" to use them... (like a power drill doesn't come with instruction on how to build a cabinet!!! lol)

thank again

---

There's a popular branching model called Flow. It's essentially a procedural map and some helper scripts. While the scripts are specifically built for git, the procedural map should be applicable to your case. Essentially:

• Master branch for live code. Nobody ever commits directly against this branch.
• Develop branch for most developing. This is where most of the work gets done.
• Feature branches for long-running features, which eventually get merged to develop.
• Release branches split from develop for feature freeze prior to release. When done, code gets merged to master.
• Hotfix branches for emergency work. These get split from master and then merged back into develop and master.