Pull request
A pull request, called a merge request on GitLab, is a proposal to merge the changes from one branch into another, usually the main branch. It shows the differences line by line, gathers review comments and runs automated checks such as tests and linters. The changes reach the main branch only once the team's rules are met, for example one approval and all checks passing.
Why it matters for a PM
The pull request is where code meets the team's quality bar, and often where a PM can try a change in a preview environment before it ships. PMs who open small pull requests (copy fixes, docs, prototypes) or review an AI agent's work need to know what makes one easy to review and safe to merge.
Example
A PM updates the onboarding emails in a pull request titled “Shorten welcome email sequence”. The description explains the goal, lists the three emails changed and links to the preview. Tests pass, a developer approves, and the change is merged into the main branch.
Key points
- A useful description explains the purpose, summarizes the change, gives testing steps and names what is deliberately left out.
- Small, focused pull requests get faster and better reviews than large ones.
- Branch protection rules can require reviews and passing checks before any merge.
- Squash, merge commit or rebase are strategies that shape the history; each team picks one.
Common mistakes
- Bundling unrelated changes in one pull request.
- Approving without opening the preview or reading the diff.
- Merging with failing checks under time pressure.
Go further with Module
The courses and lessons that cover this concept: