Thomas Heller wrote:
On Fri, Feb 10, 2012 at 4:01 PM, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
As promised: http://dl.dropbox.com/u/3512486/boost_branching_model.pdf (82 kB)
[...]
Looks good, so far. I have several questions: 1) What are all the steps which are not annotated? Updates by authors which do not work on stuff in my working set?
Just some additional commits to give the figure a slightly more "realistic" look. ;-) They might or might not affect your working set, I believe the picture would work either way.
2) What happens to that abandoned branch? Will it remain publicly visible?
Since git is decentralized, it depends on who passed the branch to which repository (it would be public if somebody pushed the branch to a central repository). However, if I'm right, the abandoned branch *will* remain available in those repositories where it has been available at all (i.e. at least the repository of the author).
3) What exactly is the purpose of the blue branch?
It contains the linear history of all releases, nothing more and nothing less. One advantage of such a master branch is that you can use merges into that branch as a trigger for running scripts. For example: a script that clones the file tree to a new directory, strips unnecessary files from the copy and finally wraps it into zip, bz2 and 7z archives with the version number in the name.
4) Will there be one big boost repository? Or will every library have their own sub repository?
Actually the branching model presented here doesn't presume any specific modularization model. You can still go either way. A monolithic Boost repository should be perfectly manageable with the gitflow branching model, though.
Thanks for further clarification,
Thank you for asking these questions, it helps me to further clarify my ideas. Also, note that the gitflow side of my picture is mostly just a reproduction of the images (and some of the explanation) over here: http://nvie.com/posts/a-successful-git-branching-model/ -Julian