Switch to a simpler branching model?

[tonyarnold]

I've been giving this some thought, and prompted by how we use git branches at my place of employment I'd like to propose a change to how we structure our branches.

Ideally, master would remain locked, and should always compile.

develop would be removed entirely — anything we're doing on develop could (and arguably should) be done on a short-lived feature branch.

We use tags to mark releases, and in addition, provide releases/1.x, releases/2.x and releases/3.x branches for bug fixes to previous releases.

I'm open to input here, but I feel like the feature-branch -> develop -> master -> tag workflow has one step too many in it (and I'm also tired of having to ask people to submit patches against develop when they invariably do so against master).

Thoughts, @magicalpanda/team-magicalrecord?

[magicalpandatest]

I am all for simplicity. I like the idea of having basically a named develop branch like releases/3.x etc and having features merged into those branches. Then having that release eventually merged into master

Sent from my iPhone

On Sep 27, 2015, at 5:11 PM, Tony Arnold notifications@github.com wrote:

I've been giving this some thought, and prompted by how we use git branches at my place of employment I'd like to propose a change to how we structure our branches.

Ideally, master would remain locked, and should always compile.

develop would be removed entirely — anything we're doing on develop could (and arguably should) be done on a short-lived feature branch.

We use tags to mark releases, and in addition, provide releases/1.x, releases/2.x and releases/3.x branches for bug fixes to previous releases.

I'm open to input here, but I feel like the feature-branch -> develop -> master -> tag workflow has one step too many in it (and I'm also tired of having to ask people to submit patches against develop when they invariably do so against master).

Thoughts, @magicalpanda/team-magicalrecord?

— Reply to this email directly or view it on GitHub.

[tonyarnold]

OK then — here's what I think we should do:

1. Create a new branch off master for release/2.x, and merge the current develop into that.
2. Update the name of the current 3.x development work if necessary;
3. Delete develop, and any other older unused branches.
4. Update the documentation.

I'll have a look at it over the coming week.

[tonyarnold]

I've actioned 1 and 3 tonight. I think the name of the release/3.0 branch is probably fine for this release, but we should aim to get what's there tidied up and merged into master soon, and then operate off short lived feature branches with pull requests.