DVCS Repo Design - separate dev from stable using branches or separate repos?

I'm working on a "plan of action" at my job for migrating our source control from SourceSafe 6.0 (ugh) to a DVCS like git or Mercurial (preferably git ATM). Right now I am working on the future repository design, i.e. branch layout and how to configure the 'central'/blessed repo(s).

Now, insofar I have only really used git as a means to push hobby open source code to GitHub and more recently for keeping my own private repo at work so that I have more fine-grained control over my code revisions than SourceSafe allows. Unfortunately I have yet to experience a wide gamut of branching/merging scenarios or other semi-complex git usage in my repos besides using simple feature branches. In other words, I don't have a lot of overall experience with DVCS', so I don't think I can predict the 开发者_如何转开发typical workflow we will use here and therefore am unable to create a matching repository design on my own.

So instead, I have spent a lot of time reading other people's git workflows and trying to best apply those strategies to how we release code at my job. I figure it's a place to start anyway, and we can change it as we go along.

Now, after looking at many git workflows, I am really liking a particular one outlined by Vincent Driessen, which seems to have a very clean branch layout that is a near-fit for how we do deployments at work (or should, anyway):

Separate Dev/Stable Using Branches

---

However, I admit to being a little confused after seeing a little different example on Joel Spolsky's HgInit site, which seems to focus more on separate repositories rather than branches for separating dev and stable code:

Separate Dev/Stable Using Repos

---

Questions

---

Is this repository-focused separation layer simply a Mercurial thing that isn't used much with git? If not, then what are the advantages/disadvantages to using this method over the use of branches for separating dev/stable code? Or am I simply completely misunderstanding what is going on here? :-)

Any input would be appreciated; I apologize in advance if this question is a waste of time due to my being steeped in ignorance.

---

In the end it's all about your preferences. I like the clones as branches model Joel covers, but they're both valid. Here's a great article that covers a few different branching models in both Mercurial and Git (despite the title):

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

My biggest piece of advice is to not over think it. I know you need a concrete proposal that management can buy in to, but if my experience repeats itself where you are you'll find that people are taking the decentralized piece pretty seriously. You'll have impromptu teams doing little side efforts on network shares, you'll have dev-to-dev cloning and pulling, and all sorts of ad hoc organization. So long as you have a few key repos with firm, clear expectations (e.g.: "must compile" or "must be shippable" or "must have Jim's blessing") you'll be fine.

---

My feeling on this is that you should avoid branching from anything but your best tested stuff. This means that all branches should be from a revision that in releases.

The reasoning for this is twofold. First, when you have a bug in a feature branch, you want to know that the bug is a result of the feature, not because of a bug in the code. Secondly, when you want to release your feature, you don't want to force any changes to come along that aren't really related to your feature.

We've gone to a strategy at work that I call the 'bushy branch' strategy.

Basically there are feature, release, hotfix and master branches. All feature branches must have a revision that was tagged in the master branch at their base and they may not merge with other feature branches at any point. They may merge with future tagged revisions in the master branch though.

Once a feature is ready, it's merged into the release branch for testing. Once it's tested, it goes into the master branch. Hotfixes are treated much as you diagram them out in your diagram.

Lastly, we have a throwaway 'integration' branch. This branch is largely automated merges of all the features that may be released soon. This branch is subjected to the daily build tests, but not necessarily the same level of rigorous testing that the release branch is. It's to catch feature interaction bugs early in the process.

I'm a Mercurial person. So I do not see that there is really a significant distinction between 'branch' and 'repository'. I, in fact, do not really like multiple branch repositories for most things as it can make it too easy to merge in branches you don't actually want to be working with. I'd rather just not have the revisions in my repo at all.