-
Notifications
You must be signed in to change notification settings - Fork 14
How to pull a merge
This policy describes how to proceed when you are going to approve a pull request. Our pull requests all require review to be approved.
Policy: Merges are only allowed if the build passes all automated checks (CI/CD pipelines, tests, linters, etc.).
Reason: A clean build ensures that the codebase remains stable and functional. Merging broken or unverified code can introduce bugs, regressions, or deployment issues.
Policy: All merges should include descriptive notes summarizing the changes, unless the commit history is exceptionally clean and self-explanatory.
Reason: Merge notes provide context for future developers (or your future self) reviewing the history. They help with debugging, auditing, and understanding the evolution of the codebase.
Policy: Use Rebase and Merge as the default strategy. The final commit message should serve as a clear summary of the feature or fix.
The Rebase and Merge option is selected using a button in the Pull Reuest dialogue that tells the Github system to execute the merge for that pull request. The strategy is configured by using a drop down on the button. The last option is Rebase and Merge.
Reason: Rebasing creates a linear and clean commit history, making it easier to follow changes. It avoids unnecessary merge commits and keeps the main branch tidy.
Policy: Always delete the feature branch after a successful merge.
Reason: This prevents clutter in the repository, reduces confusion, and encourages the use of fresh branches for new work. It also signals that the work is complete and integrated.
Policy: Ensure that all files in the pull request are marked as reviewed in the GitHub user interface.
Reason: Marking files as reviewed ensures that every change has been examined and approved by the reviewers. It helps maintain code quality and accountability.