Subject: Re: [boost] [git help] Documenting common modular boost workflows
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-10-24 06:52:09
On 24 Oct 2013 03:14, "Dave Abrahams" <dave_at_[hidden]> wrote:
> on Tue Oct 22 2013, "Niall Douglas" <s_sourceforge-AT-nedprod.com> wrote:
> > On 22 Oct 2013 at 19:45, Dave Abrahams wrote:
> >> I don't understand the source of mystery here. This is bog-standard
> >> 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
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
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
Another interesting clone of the gitflow tools/workflow is HubFlow
(Sent from mobile, apology for top-posting a wheznd broken quotes)