Re: [boost] [git/modularization] Suggested names for branches?

Subject: Re: [boost] [git/modularization] Suggested names for branches?
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-06-04 12:26:02

on Mon Jun 04 2012, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:

> Le 04/06/12 03:18, Beman Dawes a écrit :
>> At the C++Now! session discussing moving to git and modularization, I
>> showed the usual git flow overview graphic from
>> http://nvie.com/posts/a-successful-git-branching-model/ showing the
>> workflow for a library.
>>
>
>> Someone (Dave?) mentioned that the git flow choices for branch names
>> were not what we would like for Boost. I agree, but don't recall the
>> exact suggestions for more appropriate names.
>>
>> The three branches in question, with the git-flow names in parens,
>> were the main development branch (develop), release prep branches (?),
>> and the branch with actual releases (master).
>>
>> Is there a better usual convention for these names? I have a vague
>> memory of someone mentioning "master" for the main development branch,
>> "release" for the branch with the actual releases, and maybe
>> "beta-x.xx.x" for release prep branches.
>>
>> To try to avoid an extended bicycle shed discussion, perhaps people
>> could mention names they have actually seen used and know worked well.
>>
>
> Hi,
>
> I would expect to have a branch for each release and hotfix instead of
> all the releases sharing the same branch. 

If you read the git-flow docs carefully, you'll see that they don't
exactly share a branch in any trivial sense.  The system is carefully
organized to prevent out-of-control branch proliferation and encourage
forward propagation of hotfixes.

> At work I'm used to have a main branch, 

I think that's what git-flow calls "develop"

> one feature branche by feature and one release branch by release. This
> has the advantage of not needing the merge from develop to master and
> discovering that you can not merge because you depend on other parts
> that are not merged yet.

I don't think that has any advantage over the git-flow method, because
they're almost identical.  The only difference I can see in practice is
that later release branches have earlier release branches as parents.

> Which are the advantages of maintaining two parallel branches as
> develop and release? 

One obvious advantage: there's a convenient tool and lots of
documentation that support this workflow.  I'm not sure about technical
advantages.

> Why do we need to test two branches every time? 

What does "every time" mean?  It's useful to run feature-integration
tests on "develop" continuously.  It's useful to test release candidates
before they get shipped.  I don't think we can live without either one.

> I will expect that the main/trunk branch is tested every time 

Meaning, on every commit to the main branch

> and that each release branch is tested as soon as it is created and
> until it is released.

Meaning, on every commit to the release branch

> Developers needing to integrate their work could create an integration
> branch 

That's what the "develop" branch is.

> and why not they could request some testers to add this integration
> branch to be tested until it is merged to the main branch.

We have plans to support testing requests for specific branches.

> I recognize that this model could mean some more work for testers, but
> if with Git it is so simple to create branches and merge from them, I
> don't see why we should work with fixed branches.

I think you've misunderstood git-flow.  There's nothing particularly
"fixed" about the branches; they seem to work very similarly to what
you're proposing.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com