Skip to content
This repository has been archived by the owner on Feb 25, 2022. It is now read-only.

Sheriff and merge process

mwobensmith edited this page Dec 18, 2018 · 3 revisions

Once code has been approved by a reviewer, the sheriff on duty can perform a merge into the dev branch. No branches will be approved for merge into dev without the sheriff's approval.


Sheriff process

  1. Developer submits work for review via a pull request into dev.
  2. When code is approved, reviewer will indicate such in the PR.
  3. The sheriff will make an inspection:
    • Is the branch properly named for the current issue?
    • If a PR has been made, does the commit message look correct?
    • Are there any obvious issues with code quality or the commit in general?
  4. If there are problems, it gets sent back to developer and/or reviewer for correction.
  5. If it looks satisfactory, the sheriff will attempt a rebase merge.
  6. If the code will not merge correctly, the code goes back to the developer for a rebase.
  7. Once the developer has rebased, any of the parties above can attempt another PR against dev.
  8. When GitHub indicates that the code can be successfully merged, the sheriff can continue.
  9. In the comments for the PR, the sheriff will enter "fixes" or "closes" plus the number of the issue it's addressing, e.g. "Fixes #1009".
  10. The sheriff submits the PR to perform the merge.
  11. The branch is not deleted, and the GitHub issue remains open. That will be taken care of during the merge process.

Merge process

  1. On Fridays, all final check-ins are completed.
  2. Runs of Iris are performed to make sure Iris is stable.
  3. A pull request is created from dev to master.
  4. In a comment on the PR, the text "Fixes" or "Closes" is used plus the issue(s) included, e.g.:
Fixes #1001
Fixes #1003
Fixes #1004
  1. The PR is submitted as a rebase.
  2. If there are any conflicts, these are fixed either using GitHub's web interface, or locally via PyCharm's visual conflict editor.
  3. Once all conflicts are corrected, the rebase is attempted again.
  4. When the PR has successfully been completed, all included branches corresponding to the week's fixed bugs are deleted.
    Note: There is no need to close the corresponding issues, as the comment in step 4 above does this automatically.