Re: [boost] [git help] Documenting common modular boost workflows

Subject: Re: [boost] [git help] Documenting common modular boost workflows
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-10-24 23:18:19

On Thursday, October 24, 2013 3:52:09 AM UTC-7, Mateusz Loskot wrote:
>
> On 24 Oct 2013 03:14, "Dave Abrahams" <da..._at_[hidden] <javascript:>> 
> 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 
> 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? 
>

Those can be made directly to develop, but that's very different from your 
"long running branch" scenario below.
 

>
> 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/ 
>
 
Thanks; I'll read these references