Pull Request workflow

This document describes the intended workflow for making changes to the Highlander.

Branches

• master contains the current development status
• stable contains what is currently live on the workshop as the stable Highlander, for easy bug reproduction with local builds and the ability to cherry-pick fixes

Pull Requests

Changes are usually made through merging Pull Requests into master. master and stable should only rarely and under justified circumstances be directly (force-)pushed to.

One exception is forwarding the stable branch when a new workshop release is made. This may require a force-push.

Issues

Pull requests may need a separate tracking issue:

• New Feature: A tracking issue that roughly outlines the feature and a use-case
• Base-game bugfix: An issue outlining the bug, how it can be reproduced, and what may need to be done to fix it

Merging

Pull requests generally require a review to be merged. If your PR is ready for review, comment something to that effect or apply the ready-to-review label (repository permissions may be required, ask in the Discord channel). Your PR will hopefully be reviewed quickly, with two possible outcomes:

• Changes are required: Signified with the waiting-on-author label, you are expected to address review comments and update your PR. If you made the changes, apply the ready-to-review label again and use the requires re-review function to inform your reviewers you updated the pull request with their requested changes.
• Approved: Your change is eligible to be merged into master and may be included in the next beta release. Mark your pull request with the ready-for-merge label.

This flowchart should demonstrate the workflow:

Note that a previously approved PR may be found to require changes later, for example if there are merge conflicts.