On 01/05/2015 15:07, jan i wrote: > On 1 May 2015 at 15:53, Anthony Baker <[email protected]> wrote: > >> I suggest we adopt the gitflow model for branching as described in [1] and >> [2]. Following an established and consistent pattern for branching makes >> it easier for new users and devs to contribute. >> >> Here are the main gitflow concepts: >> >> 1) The master branch is reserved for production-ready code, aka releases. >> No changes are made directly on the master branch. >> > I would make an even tighter definition here. > > Master is merged solely from develop, and only by the "release manager". > Merges can only be done, when build is successful on all supported > platforms, and > the tests on all supported platforms have passed. > >> >> 2) The develop branch is the development mainline. Ongoing work shows up >> here first. >> > +1 > >> >> 3) Feature branches may be used to isolate interim work and will merge >> back to develop. >> > Public feature branches should only be used, when multiple people work on a > feature. A feature branch is started after the intention is made clear on > dev@ > > >> >> 4) Release branches are created to allow a stabilization period for a >> release while not impacting ongoing work on develop. Once a release is >> stabilized the release branch is merged to master and develop. >> > This is the purpose of master, I would not make extra release branches, > however this is close to being religious. If release branches are made they > should solely relate to master, NOT to develop. > > Instead of a branch, which is a lot of overhead, I would just use the GIT > id of master, to identify the original release.
When using the 'git-flow' extension, there's a sub-command that deals with releases. A release is started from a commit on develop and when finished merges it to master, merges to develop and creates a tag. For anyone who's not tried this, I highly recommend creating a separate test repo (you can do this locally), installing git-flow, and trying out the commands. p >> 5) Maintenance branches are created after a release (off master) to >> support ongoing hot fixes and patches as needed. This diverges slightly >> from the “hotfix” model in the original gitlfow idea but works better for >> releases with a longer life span. >> > +1, but it should be avoided, to keep the logistic (non-productive) work > volume low, try to avoid making a hotfix for older releases. > > >> Branch naming: >> - master >> - develop >> - release/vVERSION >> - maint/vVERSION >> >> where VERSION is semantic version name [3]. >> >> Actions needed: >> >> 1) Create the develop branch off of master. >> 2) Run nightly builds from the develop branch. >> > and e.g. weekly builds on master. Alternatively, whenever master is updated > run a build. > > 3) Set the default branch for the repo to develop (is this possible with >> the ASF git repo?). >> > yes > >> 4) Create a wiki page to codify the model and naming conventions. >> > +1 > >> >> Thoughts? >> > Please see my thought, not as an active developer, but as a mentor with > experience from other projects. > > >> >> Anthony >> > nice suggestion. > > rgds > jan i. > >> >> >> [1] http://nvie.com/posts/a-successful-git-branching-model/ < >> http://nvie.com/posts/a-successful-git-branching-model/> >> [2] >> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow >> < >> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow >>> >> [3] http://semver.org <http://semver.org/> >> >> > -- [key:62590808]
