This document outlines the recommended branch protection rules for the Kindling repository. These settings should be configured in GitHub under Settings > Branches > Branch protection rules.
mainThe main branch is the primary production branch and should have the following protections enabled.
Enable "Require status checks to pass before merging" with the following checks:
| Check | Job Name | Required |
|---|---|---|
| Commit Messages | Commit Messages |
Yes |
| Frontend | Frontend |
Yes |
| Rust | Rust |
Yes |
Note: Multi-platform builds run only on pushes to main and weekly scheduled runs, not on PRs. This speeds up PR feedback while still verifying builds before release.
Additionally enable:
Enable "Require a pull request before merging" with:
| Setting | Value |
|---|---|
| Required approving reviews | 1 |
| Dismiss stale pull request approvals when new commits are pushed | Yes |
| Require review from Code Owners | No (optional, enable if CODEOWNERS file exists) |
| Restrict who can dismiss pull request reviews | No |
| Allow specified actors to bypass required pull requests | No |
| Setting | Recommended | Notes |
|---|---|---|
| Require signed commits | Optional | Recommended for enhanced security |
| Require linear history | No | Allow merge commits for clearer history |
| Include administrators | Yes | Admins should follow the same rules |
| Allow force pushes | No | Never allow force pushes to main |
| Allow deletions | No | Prevent accidental branch deletion |
While not enforced by GitHub, contributors should follow these branch naming conventions:
| Pattern | Purpose | Example |
|---|---|---|
feature/* |
New features | feature/obsidian-export |
fix/* |
Bug fixes | fix/cursor-position |
docs/* |
Documentation | docs/api-reference |
refactor/* |
Code refactoring | refactor/sidebar-components |
test/* |
Test additions/changes | test/e2e-import-flow |
chore/* |
Maintenance tasks | chore/update-dependencies |
release/* |
Release preparation | release/v1.0.0 |
main as the branch name pattern# Note: This requires the gh CLI and appropriate permissions
gh api repos/{owner}/{repo}/branches/main/protection \
--method PUT \
--field required_status_checks='{"strict":true,"contexts":["Commit Messages","Frontend","Rust"]}' \
--field enforce_admins=true \
--field required_pull_request_reviews='{"required_approving_review_count":1,"dismiss_stale_reviews":true}' \
--field restrictions=null \
--field allow_force_pushes=false \
--field allow_deletions=false
The branch protection rules depend on these CI workflows:
.github/workflows/ci.yml - Main CI pipelinecommitlint job - Validates commit messagesfrontend job - Linting, formatting, type checking, testsrust job - Formatting, Clippy, security audit, testsbuild job - Multi-platform build verification
.github/workflows/security.yml - Security scanning (not required for merge)
In rare emergency situations (e.g., critical security patches), repository administrators may:
This should be extremely rare and always documented.
Release branches (release/*) may have relaxed rules to allow version bumping:
Regularly audit branch protection settings:
GitHub provides an audit log (Enterprise/Team plans) to track changes to branch protection rules.