Skip to content

Document protected branch workflow #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Parshan-MHB merged 1 commit into from
Apr 21, 2026
Merged

Document protected branch workflow #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .github/PULL_REQUEST_TEMPLATE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,3 +8,7 @@

## Screenshots

## Branch Policy

- this PR targets `main` from a non-`main` feature branch
- required CI is expected to pass before merge
16 changes: 15 additions & 1 deletion CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,21 @@

## Workflow

1. Fork the repo and create a focused branch.
1. Create a focused feature branch from `main`.
2. Keep changes scoped to one concern.
3. Regenerate the Xcode project when target or project settings change.
4. Run the strongest local verification you can before opening a PR.
5. Open a pull request into `main`.
6. Merge only after required CI is green.

Direct pushes to `main` are not part of this repo workflow. The `main` branch is protected and changes should land through pull requests, including maintainers' own changes.

Suggested branch naming:

- `feature/<short-topic>`
- `fix/<short-topic>`
- `docs/<short-topic>`
- `refactor/<short-topic>`

## Local Commands

Expand All @@ -32,9 +43,12 @@ Use `make build-ios` when you need an iOS build check and your machine has the r
- note any security or protocol impact
- include verification steps
- include screenshots for UI changes when relevant
- keep the PR focused enough to review cleanly
- do not open a PR until the branch is in a state that can pass required CI

## Before Opening A PR

- `make generate` if `project.yml` changed
- `make test`
- confirm the README and docs still match the implementation
- confirm the branch is not `main`
Loading