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