How to pull a merge

🔀 Pull Request Policy

1. ✅ Only Merge When the Build is Clean

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.

---

2. 📝 Merge Notes Are Required (Unless Exceptionally Clear)

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.

---

3. 🔄 Preferred Merge Method: Rebase and Merge

Policy: Use Rebase and Merge as the default strategy. The final commit message should serve as a clear summary of the feature or fix.

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.

---

4. 🌿 Delete Feature Branch After Merge

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.

---

5. ✅ Mark All Files as Reviewed in GitHub UI

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.