In one line
When you write code, there are several ways to branch and merge. This chapter tours the main ones.
Whichever you pick, everyone goes through a Pull Request to merge. We'll break down what a PR contains, and how all of this can be enforced with Rulesets.
Branching strategies
How a team organizes branches around PRs. Pick the model that matches your release cadence.
| Strategy | How it works | Best for |
|---|---|---|
| ๐ฟ GitHub Flow | One main + short-lived feature branches; PR โ merge โ deploy from main | Continuous delivery, most teams |
| ๐ณ Git Flow | main + long-lived develop, plus feature / release / hotfix branches | Scheduled, versioned releases |
๐ก Default to GitHub Flow for speed; reach for Git Flow only when you ship versioned releases.
GitHub Flow
One long-lived branch (main), short-lived feature branches. Branch off main, open a PR, review, merge, and deploy โ continuously. Simple and fast; ideal for web apps and small teams shipping many times a day.
- ๐ฟ Branch from
mainfor each change (feature / fix) - ๐ Open a PR early โ review and CI run on the branch
- โ
Merge to
main, then deploy immediately - โป๏ธ
mainstays always deployable
๐ก Fewer moving parts = faster feedback. The default for continuous delivery.
Git Flow
Two long-lived branches (main + develop) plus supporting branches. Work integrates on develop; a release branch stabilizes a version, then merges to main and gets tagged. Structured for scheduled, versioned releases and larger teams.
- ๐ณ
develop= integration line ยทmain= production (tagged) - ๐งฉ
feature/*branches offdevelop, merges back - ๐ฆ
release/*stabilizes โ merges tomain+develop, tags the version - ๐
hotfix/*offmainfor urgent prod fixes โ merges to both
๐ฏ More ceremony, more control. Reach for it when you ship versioned releases, not continuous deploys.
Inside a review
Today a PR can be opened by a human, a cloud agent, Dependabot, or an agentic workflow. On the diff, conversation, checks, and automated analysis converge: the place where quality is secured before merge.
| Element | Role |
|---|---|
| ๐ Propose diff | Compare branches, request merge |
| ๐ฌ Review | Line comments, approve/reject |
| ๐ค Copilot code review | AI auto-reviews every PR |
| โ Tests / CI | Required status checks must pass |
| ๐ก๏ธ Code Scanning (GHAS ยท Code Security) | CodeQL finds security vulnerabilities |
| ๐ Code Quality (standalone product) | Maintainability & reliability analysis (billed separately) |
๐
Closes #123in a PR โ the Issue auto-closes on merge.
Rulesets
Rulesets enforce merge conditions as rules, a quality gate on your branches. Configure them at the organization or repository level, and apply them top-down across many repos.
Minimal recommended setup:
| Rule | Recommended setting | Why |
|---|---|---|
| ๐ Require a pull request before merging | ON + Required approvals: 1 | Block direct pushes; every change gets at least one review |
| ๐ก๏ธ Require status checks to pass | Require tests + Require branches to be up to date before merging | Merge only when CI is green and validated against the latest main |
| ๐ Require code scanning results | Require CodeQL results (block by severity) | Stop merges while unresolved security alerts remain |
| ๐ Block force pushes | ON | Prevent destructive history rewrites |
| ๐ค Automatically request Copilot code review | ON | Copilot pre-reviews every PR automatically |
๐ฏ Stop manual gatekeeping; let rulesets enforce top-down.
โ PRs in the AI era
With AI shipping PRs en masse, some ask โare PRs still needed?โ But to keep a repo understandable and safe, this gate is necessary.
- ๐ค Copilot auto-review catches issues early
- ๐ ~90M merges/month in 2026 (~2x)
- ๐ Humans approve, AI does the prep
๐ก Guard the PR and go faster = Rulesets ร Copilot.