On 24 Oct 2013 03:14, "Dave Abrahams"
on Tue Oct 22 2013, "Niall Douglas"
wrote: On 22 Oct 2013 at 19:45, Dave Abrahams wrote:
I don't understand the source of mystery here. This is bog-standard Git usage:
cd my/submodule/directory git checkout develop # make edits
Umm, shouldn't you create a new branch here for the change rather than changing develop directly:
git checkout -b issue_8_fix develop #make edits git commit -a git checkout develop git merge issue_8_fix git commit -a
No, working directly on the develop branch is an allowed option; the lack of a feature branch affects nobody but the developer. If you won't have multiple features in flight at once, there's no reason you have to create feature branches.
It can get a bit awkward if you want to start a new feature while you're still using develop to work on a different feature.
What about accumulation of small features, small fixes and improvements which do not necessary qualify as hotfix release managed with the gitflow hotfix branches? I've been using gitflow to maintain SOCI for months now and it's proved that master/develop is not always sufficient to cover all cases, especially with various GitHub pull requests flowing from users/contributors. I personally found a need for Subversion's equivalent of long running /branches/X.Y, hence I'm trying to incorporate support branches. Here is my post to gitflow-users with the problem/case explained, not sure if it applies to Boost directly, but I'm curious how Boost will manage such cases: https://groups.google.com/d/msg/gitflow-users/uvy0b4OrgnY/B1E-hb9lS6wJ By the way, the original nvine/gitflow seems not actively maintained. It's worth to check AVH Edition of gitflow, it fully implements the support branches. Another interesting clone of the gitflow tools/workflow is HubFlow http://datasift.github.io/gitflow/ Mateusz Loskot (Sent from mobile, apology for top-posting a wheznd broken quotes)