You've finished a feature, pushed it to a branch, and now someone needs to check it before it reaches main. The code may compile locally, but another engineer still needs to understand the change, inspect the diff, run or review automated checks, and decide whether it's safe to merge. That's the moment a pull request, usually shortened to PR, becomes useful.
If you're asking what is a PR in GitHub, the short answer is this: it's a formal proposal to merge changes from one branch into another. The useful answer goes further. A PR is also the shared workspace where people discuss the change, CI reports whether it passes, branch protection applies repository policy, and the team keeps a record of the decision. GitHub describes pull requests as its key collaboration feature for discussing and reviewing changes before merging, and the GitHub pull request documentation explains that anyone with read access to a repository can create one.
Table of Contents
What a Pull Request Actually Is
Suppose you're adding password reset to a web application. You create a branch from main, make the changes, run tests, and push the branch to GitHub. Your work exists in the repository, but it hasn't become part of the application's shared baseline.
You open a pull request from feature/password-reset into main. GitHub compares the source branch with the target branch and displays the proposed changes. Your teammate can read the description, inspect each modified file, leave inline comments, request changes, or approve the work. Automated workflows can also report whether the branch builds and passes its checks.
That's why a PR isn't just a visual diff.
Practical rule: Treat a pull request as a decision record around a proposed merge, not as a message that says “please look at my code.”
PR versus a plain Git merge
A local Git merge combines histories. You can merge one branch into another from a terminal without creating a pull request at all. GitHub's PR workflow adds the collaboration layer around that operation:
Discussion: The author explains the change and reviewers ask questions in a persistent thread.
Review: Reviewers can approve the work or request changes, with comments attached to specific lines.
Automation: CI workflows report build, lint, test, and security results in the PR.
Governance: Repository rules can require approvals or successful checks before merging.
Traceability: The conversation, review decisions, commits, and merge event stay connected.
GitHub's own definition centers on proposing a merge between a source and target branch, while the operational value comes from bringing all those signals into one place. Distributed teams use that hub to coordinate changes without requiring every engineer to work in the same office or time zone.
PRs also work for more than traditional human authors. Coding agents can create branches, push commits, open pull requests, and respond to review comments. That adds automation to the workflow, but it doesn't remove the need for a clear proposal and an accountable merge decision.
The Anatomy of a GitHub Pull Request
A new PR can look busy because GitHub puts several kinds of information on one page. Each area answers a different question, so reading it in the right order helps.
Start with the proposal
The title should identify the change quickly. “Add password reset email flow” tells a reviewer more than “Updates.” The description supplies the reasoning and boundaries. Explain what changed, why it changed, how you tested it, and anything a reviewer should examine carefully.
GitHub supports Markdown, task lists, and links to issues. A useful description might include:
Problem: Users couldn't recover access after forgetting a password.
Implementation: Added token creation, expiry handling, and the reset form.
Testing: Ran the relevant unit and integration checks.
Review focus: Please pay particular attention to token invalidation.
This is the author's pitch, but it shouldn't read like marketing. It gives the reviewer a map before they enter the code.
Read the history and the diff
The Commits tab shows the pushes made to the branch. It helps a reviewer understand how the work developed, although the final review should focus on the resulting change rather than judging every exploratory step.
The Files changed tab is where most code review happens. GitHub displays the difference between the source and target branches, with additions, deletions, and surrounding context. Reviewers can comment on individual lines, suggest edits, and create threaded discussions.
The Conversation area collects the broader discussion, review summaries, linked issue activity, and status updates. It answers questions that don't belong to one line of code, such as whether the product behavior matches the requested feature.
Check ownership and readiness
The sidebar can show requested reviewers, assignees, labels, linked milestones, and the current review state. These fields help route the work and signal whether the PR is ready for a final decision.
At the bottom, the Checks area reports workflow results. If the repository uses required checks, the merge controls reflect those results. The page therefore moves from intent, to implementation, to discussion, to evidence, and finally to a merge decision.
How a Pull Request Moves Through Its Lifecycle
A PR begins before anyone clicks Open pull request. The author first creates a branch from an appropriate base, usually main, and gives the branch a focused purpose. They make the change, commit it, and push it to GitHub.
The author then opens a PR with a specific title and enough context for another engineer to review it. If the code is still exploratory or incomplete, the author can mark it as a draft. A draft tells the team that feedback may be welcome, but the author isn't asking for final approval yet.
Review happens in a loop
GitHub Actions or another CI system usually starts checks when the PR opens or changes. The author should also review their own diff before requesting teammates, because self-review catches accidental files, debug output, unclear naming, and changes outside the stated scope.
After reviewers are requested, they may approve the PR, leave comments without blocking it, or request changes. The author can answer questions, push new commits, and resolve threads once the underlying issue is addressed. A new push may trigger checks again and can affect whether previous approvals remain valid, depending on repository rules.
A PR isn't a one-way handoff. It's a controlled loop of proposal, evidence, feedback, revision, and decision.
Here's a short walkthrough of the merge moment before the next phase of the workflow.
Merge or close
When the required reviews and checks are complete, an authorized person selects the repository's permitted merge method. GitHub records the merge, and the team may delete the source branch as cleanup. If the change must also reach a maintenance or release branch, the team needs a deliberate backport process rather than assuming the original merge handles every branch.
A PR can also be closed without merging. That outcome means the proposed change won't enter the target branch, but the discussion and review history remain available. Teams may close a PR because the work is obsolete, superseded by another approach, or no longer aligned with the product.
Choosing the Right Merge Strategy
The merge button hides a history decision. GitHub commonly presents three strategies, and each produces a different shape on the base branch.
Assume a feature branch contains four commits: an initial implementation, a test, a bug fix, and documentation. The strategy determines whether main preserves those separate steps or records the work as one unit.
| Strategy | History on Main | Best For | Trade-off |
|---|---|---|---|
| Merge commit | Preserves the branch's commits and adds a merge point | Feature branches where the full branch history matters | Can make the history harder to scan |
| Squash merge | Combines the PR into one commit on the base branch | Focused changes where main should show one coherent unit | Hides the branch's intermediate commits |
| Rebase merge | Replays the individual commits on top of the base branch without a merge commit | Teams that want a linear history while retaining separate commits | Requires disciplined commit structure and careful handling of rewritten history |
What changes on main
With a merge commit, the four commits remain visible as part of the branch's history, along with a commit showing where the branch joined main. That can help when the development sequence matters or when teams use branch topology during debugging.
With squash merge, reviewers may see all four commits in the PR, but main receives one combined commit. This often makes reverting the entire feature straightforward, provided the combined commit represents one coherent change.
With rebase merge, the commits remain separate, but GitHub places their rewritten versions directly on top of the current base. The result is linear without an additional merge commit.
No strategy is universally correct. Team size, release cadence, debugging habits, and changelog tooling all influence the choice. A small team might value a simple linear history, while another team may need visible branch structure. Repository administrators should choose and restrict the allowed methods so engineers don't make an arbitrary history decision for every PR.
Pull Requests as the Hub for CI and Branch Protection
A PR becomes a governance gate when the repository connects it to CI and protected-branch rules. GitHub documents that protected branches can require a specific number of approving reviews and passing status checks before a merge can happen, as described in its branch protection guidance.
Consider a PR that changes a TypeScript service. The author opens it, and CI starts a typecheck, test suite, lint job, and build workflow. The typecheck fails, so GitHub reports a failed check and disables the merge path under the repository's protection rules. A teammate reviews the failure, the author pushes a fix, and the relevant workflow runs again. Only after the required evidence passes can the review proceed toward approval.
Several controls meet in one place
Branch protection can enforce requirements such as:
Required reviews: A PR needs approval from the required reviewers before merge.
Required checks: Build and test workflows must report success.
Stale review handling: New pushes can invalidate earlier approvals when the change needs fresh review.
Push restrictions: The repository can limit who may update a protected branch.
History rules: The team can require a linear history or restrict permitted merge methods.
Ownership rules: Code owner patterns can route sensitive directories to designated reviewers.
These controls work because the PR is the execution and decision context for the change. GitHub notes that workflows related to pull request reviews run in that context, and security-sensitive automation must distinguish the pull request head from the merge ref. That distinction matters because the code proposed by an external or untrusted contributor isn't the same security object as GitHub's simulated merge result.
Teams integrating automated agents or deployment previews can connect GitHub through Sokko's GitHub integration, while still keeping branch protection and human approval as explicit controls. The implementation should be deliberate. A check that never reports, a reviewer rule aimed at the wrong branch, or a workflow with unsafe permissions can block delivery or weaken the gate.
How AI Agents Are Changing the PR Workflow
The classic PR had two actors: an author and a reviewer. AI coding agents add a third participant that can create code, inspect feedback, and update the branch.
A typical workflow might start with a task in Linear. An agent reads the ticket, creates a branch, writes the implementation, and opens a PR. CI runs against the proposed branch. An automated reviewer posts findings, the agent pushes a follow-up commit, and a human reviews the final behavior before approving and merging.
That sequence changes the human role. Engineers still need to set architecture, define acceptable behavior, check security boundaries, and make the final decision. They may spend less time explaining basic syntax and more time evaluating whether the change belongs in the system at all.
The review surface gets more important
An agent can produce a technically valid diff that still lacks product context. The PR description therefore needs to state the intended behavior, constraints, test coverage, and known limitations. Commit structure also matters because reviewers need to tell whether a later commit fixes a real issue or merely obscures the original change.
Automation can increase review volume and create new collisions. One empirical study of AI coding-agent PRs reported 29K+ conflicted PRs and a 27.67% conflict rate in one dataset, while replayed three-way merges showed 41.7% conflict rates for cross-agent pairs versus 19.8% for intra-agent pairs in another analysis, as documented in the study of conflicts in agent-generated pull requests. These figures apply to those datasets, not to every repository, but they illustrate why parallel agents need branch coordination and conflict-aware workflows.
A live preview can make review more concrete. Instead of reading a UI diff without context, a reviewer can open the branch in an isolated environment, exercise the changed flow, and then return to the PR with a more informed judgment. Sokko describes this agent-to-devbox pattern in its explanation of AI coding agents, where an agent's branch can be connected to a running preview.
The practical shift is clear: the PR is becoming the integration surface for humans, CI systems, review bots, coding agents, and preview environments. The more actors you add, the more important explicit ownership, narrow scope, and protected merge rules become.
Practical Tips for Smoother PRs and Reviews
A reviewer moves faster when the author removes avoidable uncertainty. Start with a title that uses an imperative verb, link the relevant issue or ticket, and explain the behavior rather than repeating the branch name.
For a UI change, include screenshots or a recording when the repository's policy allows it. Add a short test plan that tells the reviewer what you ran and what they should try manually. A useful PR description answers three questions before the first comment arrives: what changed, why it changed, and how someone can verify it.
Write for the next reviewer
Keep the code reviewable:
Limit the scope: One PR should usually address one concern. Separate a refactor from a behavior change unless combining them is necessary.
Use coherent commits: Each commit should represent a meaningful step. Clean up fixup noise before merging if the team preserves individual commits.
Self-review first: Read the rendered diff, not only the files in your editor. Look for generated artifacts, unrelated formatting, and missing tests.
Use draft status early: Open a draft when you need design feedback before the implementation is complete.
Choose stacking carefully: Stacked PRs can split a large dependency chain into focused layers, while a long-lived feature branch can reduce coordination overhead for work that must land together.
State review needs: Tell reviewers whether you want an architectural discussion, a correctness check, a visual check, or final approval.
Reviewers also control throughput. Set a team expectation for responding to review requests, ask questions when intent is unclear, and use suggested changes for small, mechanical edits. An approval with comments can be appropriate when the comments are follow-ups rather than merge blockers. Blocking approval should signal a concrete issue that must be resolved.
Reviewing well means separating “this must change before merge” from “this could be better later.”
Small PRs work especially well with required CI checks and automated reviewers because each signal applies to a narrower change. A devbox platform such as Sokko Devbox can also give a team a branch-specific running environment for browser-based verification, which is useful when a diff alone doesn't show the complete behavior.
A pull request is therefore more than a GitHub button. It's a structured path from branch to shared code, with a written proposal, review conversation, automated evidence, policy checks, and a recorded decision. Once you understand that role, the right question stops being only “what is a PR in GitHub?” and becomes “what information does this PR need so the team can make a safe decision quickly?”
Sokko lets AI agents work against GitHub repositories, open and update pull requests, and run branches in isolated devboxes with live preview URLs for human testing. Visit Sokko to connect your repository workflow to managed agents and review changes in a running application instead of relying on diffs alone.