Learning Objectives
By the end of this lesson you will be able to:
- Describe each stage a Pull Request passes through
- Explain what a PR is in Git terms, and what is platform-specific
- Read a PR page and extract the information a tester needs
- Identify the points in the cycle where QA adds the most value
What a Pull Request Actually Is
Git itself has no concept of a Pull Request. There is no git pull-request command. A PR is a feature of the hosting platform — GitHub, GitLab (where it is called a Merge Request), Bitbucket, Azure DevOps.
What it wraps is entirely ordinary Git:
- A source branch on the server, with some commits
- A target branch, usually
main - A diff — precisely
git diff main...feature-branch - A conversation attached to that diff
- A merge that eventually happens, or doesn't
Everything you learned in Modules 1 and 2 is underneath it. The PR adds review, discussion, automated checks and an audit trail — the human process around the merge.
The Stages
1. Branch and work
A developer branches from main, commits, and pushes:
git switch -c feature/PAY-4102-new-auth-flow
# ... work ...
git push -u origin feature/PAY-4102-new-auth-flow
Nothing has been proposed yet. The branch just exists on the server.
2. Open the PR
They open a Pull Request from that branch into main, with a title, a description and usually a ticket link. This is the proposal: please review this before it becomes part of main.
Most projects run automated checks the moment it opens — build, lint, unit tests, sometimes a preview deployment.
3. Review
Reviewers read the diff and comment. Comments attach to specific lines, so a discussion about line 41 stays next to line 41 rather than getting lost in a chat thread.
This is where QA belongs, and where most testers are absent. You are looking for different things than a developer reviewer: missing negative cases, unhandled boundaries, error paths that swallow failures silently, changes with no corresponding test.
4. Changes
The author pushes more commits to the same branch. The PR updates automatically — no new PR, no re-opening. The diff, the checks and the conversation all follow along.
This is why PRs are conversations rather than submissions. It is completely normal for one to go through several rounds.
5. Approve
Reviewers approve. Many projects require a set number of approvals and passing checks before the merge button becomes available at all.
If your team includes QA in that requirement, your approval is a gate. If it doesn't, a clear comment saying "tested locally, auth suite green except the known flake in X" still carries real weight.
6. Merge
The branch is merged into main, usually with one of three strategies:
| Strategy | Result |
|---|---|
| Merge commit | Full history preserved, plus a merge commit (--no-ff from Module 2) |
| Squash and merge | All the branch's commits combined into one commit on main |
| Rebase and merge | Commits replayed onto main, linear history, no merge commit |
Worth knowing which your team uses, because it changes what you will see later. Under squash, that fifteen-commit branch becomes a single commit — so git blame will point at one commit for the whole feature, and the individual steps only survive on the branch.
7. Close
The PR closes and the branch is usually deleted automatically. The PR page itself stays forever: the diff, the discussion, the checks. It is a permanent record of why this change was made and who agreed to it.
That archive is genuinely useful during an incident. Finding the PR that introduced a change and reading its discussion often explains the intent far better than the commit message did.
Reading a PR as a Tester
Six things to extract, quickly:
- The branch name — you need it to check the code out (next lesson).
- The ticket link — the acceptance criteria live there, not in the PR.
- The files changed tab — your test scope, listed for you.
- The checks — a red pipeline means don't start manual testing yet.
- The description — often says what the author didn't test, which is a gift.
- The commit list — small, focused commits usually mean a change you can reason about.
Pro Tip: On the Files changed tab, look for source files that arrived with no matching test file. That single observation, left as a comment, is one of the highest-value things a tester contributes to code review — and it takes ten seconds to spot.
Where QA Adds Most
The stages are not equally valuable to be present at:
- At review — cheapest possible moment. A missing edge case caught here costs one comment; caught after release it costs a hotfix.
- After the author pushes changes — re-checking that the fix actually addresses what you raised.
- Before merge — the local test run that turns "looks fine" into "I ran it".
The next two lessons cover exactly how to do that last one.
Key Takeaways
- A Pull Request is a platform feature wrapped around ordinary Git branches and diffs
- The cycle: branch → open → review → changes → approve → merge → close
- Pushing to the branch updates the PR automatically; it is a conversation, not a submission
- Merge, squash and rebase strategies produce different histories — know which your team uses
- The PR page is a permanent record of intent, and is valuable long after the merge
- A source file with no accompanying test change is the easiest high-value comment a tester can leave