I've been thinking a lot about best practices regarding branching in distributed version control systems such as git an mercurial (the two dvcs's I have experience with and use on a daily basis).
The way I've been doing it is slightly different in each of these, but generally follows these guidelines:
- master branch - concurrent with production code
- development branch - concurrent with "beta" code
- feature branches - for feature development
Development is done in a feature branch (usually created off of the master branch, so we know we're working with a stable code base), and when dev is completed, reviewed, and developer-tested, it's pushed/merged into the development/beta branch, put out on a beta server, and tested.
If all goes well, the feature is approved, and we can merge it into the master/stable branch, stage it, do final testing, and get it into production.
If it doesn't go well, though, things break down. If, for instance, a feature is scrapped or just delayed indefinitely, we probably want to remove it from the dev/beta branch. However, since merges from master/stable (hotfixes, content changes, etc.), and other new features have probably been put into the dev branch, it becomes difficult to remove a single feature from that branch.
I'm coming to the conclusion that this workflow is just broken, but it seems like it should work. So, specifically:
- Is it possible to remove a particular feature from this type of branch?
- Is this just a broken workflow?
And more generally:
- Given long-term development of features, and a need to have a branch concurrent with live, what are the best practices involved in dvcs?