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.
> 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
> 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
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
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk