On 01/05/2015 14:53, Anthony Baker 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. > > 2) The develop branch is the development mainline. Ongoing work shows up > here first. > > 3) Feature branches may be used to isolate interim work and will merge back > to develop. > > 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. > > 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. > > 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. > 3) Set the default branch for the repo to develop (is this possible with the > ASF git repo?). > 4) Create a wiki page to codify the model and naming conventions. > > Thoughts? > > Anthony
+1 p > [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]
