Branching

Branching

Like the exercise, it's probably best that we avoid doing work directly on the master branch. To keep things clean, I propose we use a scheme similar to the exercise:

When you are going to work on a specific task, do the following:

• Create an issue or respond to a relevant issue, announcing your intentions. Include any relevant user stories in your issue.
• Create a new branch. The branch name should include the corresponding issue number, and we should be able to generally tell what you're working on based on the name.
• Complete the work, verify your work, and announce completion. Others will give it a look-see, and it will eventually be merged back into the master branch.

Note: there's no real need to wait for the branch to be merged to master to use the work in that branch. If you see a completed branch that has new dependencies that you need (e.g. you're planning to create an HTML template, and the new branch has completed models that you need), take it and run away to a third branch, using the same style. We're on a pretty tight timeline, so we can't really afford to wait around for verification.

I would also suggest that unit tests do not require their own branch. None of our code should ever be dependent on unit tests, so the chances of you breaking something in the master branch are nil. Just make sure you have a clean copy of the master branch before writing the unit tests.

I'll edit this as we go, in the event that we find the need for standards and operating procedures. ALSO SORRY FOR SPAM, I'M DONE CREATING ADMIN ISSUES