Feature branches are valid reasons to branch, provided they are short lived and there aren't too many of them active at the same time.

Branching with a DVCS is a normal process. The local repository is basically a branch. I work there all the time then merge back to master when things are working.


>
>I totally disagree with this as well, although I do agree with the underlying premise that you want to keep your development or master branch clean so that you can run CI tools properly.
>
>Personally, with Git I run on a development branch always, and then use local only feature branches to work on specific features that always merge back to development. Then only tagged releases go on master whenever there's a fixed release version that should be tagged. I can run CI tooling on the Development branch since that's my active work branch where I care about CI features... Master is just for 'show' to the outside world where people can see the last stable point. Development is the active work branch and all other branches for the most part are shortlived private work branches that typically merge back to Development.
>
>Branching in DVCS is natural and if you read from the gurus in this space you'll see that the recommended workflows do exactly that. Look at any bigger project on Github and you can see the many feature branches that are used and eventually merged back to a core working branch (or master).
>
>There are lots of different approaches for using branching (or not branching at all) that provide valid choices and running a single branch is certainly one option - one that works particularily well for small team or single developer development.
>
>But running a DVCS on a single branch seems silly because you're essentially shoehorning a DVCS into a CVS workflow.You're giving up all the benefits of being able to easily roll forwards and back to multiple parallel work flows( ie. you separately work on Feature 1 and Feature 2), which you simply cant do with a single branch.
>
>
>+++ Rick ---