GitHub
There is plenty you can do just using the GitHub web interface.
Create a new GitHub repository
- Go to GitHub and create a new repository. You can do this by clicking the "+" icon in the top right corner and selecting "New repository".
- Name your repository (e.g.,
my-new-project), add a description, and choose whether to make it public or private. - Initialize the repository with a README file and choose a license if desired.
- Click "Create repository".
- Copy the URL of your new repository (e.g.,
https://github.com/username/my-new-project.git).
Protect the main branch with a ruleset
A branch ruleset controls which changes can reach main and helps prevent accidental deletion or history rewrites. The following settings are a recommended starting point for a repository maintained through pull requests.
Open the repository's Settings, find Rulesets in the sidebar, and select New ruleset → New branch ruleset. You need repository administrator access or permission to edit repository rules. Branch rulesets are available for public repositories on GitHub Free; private repositories require GitHub Pro, Team, or Enterprise Cloud. See GitHub's ruleset setup instructions.
Recommended settings
Use an explicit branch target so the rules apply to the intended branch.
| Setting | Recommendation |
|---|---|
| Ruleset name | Protect main |
| Enforcement status | Active |
| Target branches | Add a target → Include by pattern, then enter main. Alternatively, select Include default branch to follow the repository's default branch. |
| Bypass list | Leave empty so the rules also apply to administrators. |
| Restrict deletions | Enable. |
| Block force pushes | Enable. |
| Require a pull request before merging | Enable. |
| Required approvals | 1 when another reviewer is available; 0 for a sole maintainer. |
| Dismiss stale pull request approvals when new commits are pushed | Enable when requiring reviews. |
| Require approval of the most recent reviewable push | Enable when another reviewer is available; leave disabled for a sole maintainer. |
| Require conversation resolution before merging | Enable. |
| Restrict creations / Restrict updates | Leave disabled for this workflow; these restrict creation or updates to bypass actors. |
Require code-owner reviews only with maintained ownership assignments. Enable signed commits, deployment requirements, or scanning requirements after configuring their prerequisites. Require linear history only if the project uses squash or rebase merging. See GitHub's rule definitions.
Require status checks when CI is ready
Continuous integration (CI) checks provide automated validation before merging. Once CI runs reliably on pull requests, enable Require status checks to pass before merging, add the relevant test, lint, or build checks, and select their expected GitHub App source where available. Enable Require branches to be up to date before merging to validate against the latest base branch; this requires at least one configured check. See status-check settings.
For GitHub Actions, ensure required workflows run on pull_request events targeting main. Do not require a workflow that only runs after a push to main. Workflow-level path or branch filters can skip a required workflow and leave its check pending, blocking unrelated pull requests. Confirm the check names from an actual run and use unique job names across workflows. See troubleshooting required status checks.
Save and verify
Click Create, then open a small pull request to confirm that the ruleset targets main and that the merge panel shows the expected review and check requirements. An Active ruleset takes effect immediately.
If an exception is necessary, remember that bypass access covers every rule in that ruleset. Keep deletion, force-push, and CI protections in a separate ruleset with no bypass, and place only the review or pull-request requirements in the exception ruleset. For pull requests only retains the pull-request requirement; Always allow permits direct pushes subject to other applicable rules, including required checks. See bypass permissions.
Next steps
Now you may want to learn how to use Git