Decide and codify git-flow practices

[hawkw]

Now that we have a dev release on master, we need to agree on better git flow practices for Alexandria development. I've just been working directly on master (and occasionally breaking things), which I think we can all agree is Bad. We ought to decide on a better Git model and put it in /doc right away.

Since we don't have a whole lot of developers working concurrently, we shouldn't need a very complicated branching model. Something like frontend-dev and backend-dev branches merged into develop and then master would probably be reasonable, although we could use individual feature or release branches if we wanted to go with a more complex model.

I know @redbassett has some opinions on this subject, so I'll let him determine what we ought to do. I'm happy to go with whatever you think seems appropriate.

[redbassett]

Dev branch(s), and we should submit to master only with pull requests.

[hawkw]

Okay. Do you want to PR feature branches into release branches that are then PRed into master?

[redbassett]

I'm not sure going into release branches, but release branches should be PRd into master.

[hawkw]

I'm not sure going into release branches, but release branches should be PRd into master.

Uh.

[redbassett]

I'm not sure if release branches need PRs to accept code.

[hawkw]

Oh, okay. I just kind of had a hard time parsing that. I kind of like PRing everything even on projects that are just me, just so I can ensure that the merge builds on CI.

[hawkw]

I like this model but I don't think we have enough devs to necessitate using quite so many separate branches. I don't know if we need a develop branch; I think we can go with a general model of "fork release branches from master, fork feature branches off of release branches, merge features to release, merge releases to master" with access to master being PR-only, definitely.

[redbassett]

That is essentially the model I use, but yeah, I don't branch that much. I generally have a main "develop branch", build features from that, and then release branches to snapshot the current state of develop before PRing to master.That way develop is always the "nightly build" and release branches are pre-releases (until merged).

[hawkw]

Hmm, yeah, that makes sense. It seems worth having a main develop branch then to generate dev builds from. Shall we just go with that?

[hawkw]

Do you think feature branches ought to live in redbassett/alexandria and hawkw/alexandria to avoid polluting the main namespace?

[hawkw]

Now with develop.

[hawkw]

Some other things we might want to consider doing:

• Travis deploys builds of develop to GitHub Releases as prereleases?
• Travis doesn't announce build status for feature branches if there end up being a lot – individual devs can check the status of their branches if they want to