Revision Control Policy

To ensure that our source control repository remains neat, tidy, and functional, there are a few guidelines we're following.

Master Branch Rule

Never push to the master branch. Never pull from the master branch to make source code changes. The project leads will pull changes into master from the development branch when milestones are met.

When You Need To Modify The Source Code

This is purposefully an ordered list.

1. If there is no related issue on the issues list, create one that describes the task you're doing.

2. Checkout from the development branch.

   git checkout origin development

3. Create a new branch that has the related issue number in the name.

   git checkout -b issue_117

4. Push your new branch to GitHub.

   git push origin issue_117

5. Now you're ready to make any changes you need to accomplish the task. Remember to both commit and push to GitHub often. There is no concern if you "break the build" or push only part of your solution because you are isolated to your own branch.

6. When you've finished your task, file a Pull Request from your branch into development. This allows us to review your code changes before they are merged into development.

   Do not push to the development branch until a project lead has verified your code changes. We do need to keep development in good order so that other's checking it out for their branches can start their tasks from a working code base.

   We will mark your issue as resolved if the code changes are accepted.

Before starting work on another task, remember to switch back to the development branch first. If you're still on your issue branch, and you create a new branch, you'll be branching your issue instead of the working development branch. This is problematic later on when we have to do branch merging.