search

alexandrialibrary / Alexandria

Alexandria is a simple little card catalogue webapp with a terribly pretentious name.
MIT License
2 stars 1 forks source link

Decide and codify git-flow practices #64

Open hawkw opened 9 years ago

hawkw commented 9 years ago

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 commented 9 years ago

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

hawkw commented 9 years ago

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

redbassett commented 9 years ago

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

hawkw commented 9 years ago

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

Uh.

redbassett commented 9 years ago

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

hawkw commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

hawkw commented 9 years ago

Now with develop.

hawkw commented 9 years ago

Some other things we might want to consider doing: