Use gitflow

[kaleyh]

I noticed that this repo only has one "master" branch. When there are a group of people all working on separate features, some of which conflict with each other, keeping things in separate branches is a must. This is incredibly useful at hackathons when someone might want to try something a bit radical, but you don't want the tangent to get muddled up with everything else.

This proposes an extremely solid git workflow: http://nvie.com/posts/a-successful-git-branching-model/

For a small project, you really only need the master, develop, hotfix, and feature branches. Release branches are a bit much (I think).

[brendam]

I'd be happy to use this, seems like a lot of projects do.

[brendam]

This is interesting http://stackoverflow.com/questions/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github-flow

[jamiereid]

Might be worth organising a get together to go over this in person. Thoughts?

[kaleyh]

I usually use the github-flow model. I agree with most of the answers on that stack overflow; and certainly for a project like this, the github model is more appropriate. I guess I've been lazy with testing in the past, and bugs would often have been introduced when developing new features, and made it into production. Having a separate develop branch meant that these bugs were caught before hitting the prod servers.

tl;dr test everything twice, deploy often

[merk]

As long as you're actually writing tests and have a CI environment set up (ie, travis) to run tests for you it isnt likely you'll end up with bad code in production. It is after all, up to the release manager to merge, test and then tag a new release which can then be pushed into production.

[jamiereid]

I'd agree, at least in the instance of GovHack, that we deploy often