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.