Hypothetical DVCS (git) workflow for VDrift - Part I Corollary

So, you don't want a staging branch after all?

Part one dealt with a tree that has a separate major branch strictly for bugfixes during a release cycle, but your project has only the stable and development branches. This represents a fundamental difference in workflows, but what does it mean?

In the first instance, staging more or less allowed development to continue unhindered during the entire release cycle. You don't really have any other options than this in centralised version control systems, but in DVCS everyone can have a repository that they individually commit to and can publish, meaning that the repository that mainline releases are – well, released – from is free to be dedicated to that purpose.

Differences in master

In the three branch model, closing the merge window for a release involved performing an actual merge from master into staging. In the two branch model, the close is more a change of state for one branch, essentially the difference beween open and closed master is in what is allowed to be pushed to it. While the merge window is open, this includes more or less anything that will go into the next release. After it closes, this should be limited to code changes that fix bugs only.

This does not mean that no one can work on new features in this time. On the contrary, it's as good a time as any to be working on the following release so your feature can be merged early on. Everyone is still capable of sharing code with each other, and extra branches in the main repository for specific feature sets for an as-yet-undefined release is possible. In effect, master has become staging.

Differences in stable

One of the benefits (probably the main benefit) you lose in this model is the clarity of merging bug fix commits from staging in sets. After release, bug fixes for that release have to be applied directly to stable, and if a different solution must be applied to master then reverts have to be made directly to stable also, although hopefully this is a rare occurence. A side effect of this is that fixes that cause a problem elsewhere become more devastating, but that's not a problem because you wouldn't apply a fix without checking it first now, would you? ;)

That's more or less all for now. See you soon for part two.