Code change procedure

Overview of git branch strategy

The Loom development team follows the successful git branching model described by Vincent Driessen

master represents the latest stable release
development represents the latest development version, which might not yet be released. Unit tests and smoke tests (a lightweight integration test) should run and pass on every development commit.
feature branches are used for developing new features, and are eventually merged back into development through Pull Requests. They can be named anything, and tests aren't necessarily expected to pass on every commit. You may want to name your feature branch for the corresponding issue number that you are working on, e.g. issue-516.
release branches are used if needed to isolate release candidates from from new changes going into development branch. They are named "prerelease-" followed by the release version being prepared, e.g. "prerelease-0.1.1". Releases on this branch will be tagged "0.1.1rc0, 0.1.1rc1, ... " up to the final release with tag "0.1.1"

Create a feature branch (typically from the development branch; sometimes from a release branch, if patching an older released version)
Make the changes. Commit to the feature branch as often as needed. Jenkins will run unit and smoke tests for every commit, but there is no expectation that tests should always pass on a feature branch.
Create a pull request to merge the changes into the source branch (typically into the development branch; sometimes into a release branch, if patching an older released version).
Assign a reviewer.
Reviewer: ** Verify that Jenkins tests pass. Test result is visible on the PR page in GitHub. ** Inspect the source code. ** If the PR is not acceptable, leave a note for the submitter, who can then follow up with new commits to the feature branch to submit the necessary changes. ** If the PR is acceptable, use the "Squash and Merge" button on the PR page in GitHub to complete the merge.