What is a pull request, and how does the code review workflow work?
A pull request (PR) is a request to merge your branch into another branch, usually main. You push a branch, open a PR with a clear description, automated checks run, teammates review and comment, you push fixes, and once approved the PR is merged and the branch deleted.
Explain it simply
In a team, you do not push straight to main. Instead you work on your own branch, and when you are done you raise your hand and say "please check this and add it to main". That raised hand is the pull request. GitLab calls the same thing a merge request.
The PR page shows exactly what changed, line by line. Teammates read it, ask questions, suggest improvements, and approve it. Automated checks, like tests and linting, run on it too. Only after that does the code reach main.
Example
You are fixing a bug where the signup form accepts an empty phone number.
git switch main
git pull
git switch -c fix/phone-validation
# edit the code
git add src/signup.js src/signup.test.js
git commit -m "Reject empty phone number on signup"
git push -u origin fix/phone-validationOn GitHub, you click "Compare & pull request" and write:
Title: Reject empty phone number on signup
What: Adds a required check and a 10-digit format check for the phone field.
Why: Users could sign up without a phone number, so OTP login failed later (issue #142).
How to test: Open /signup, leave phone empty, press Submit. You should see "Enter a valid phone number".
Tests: Added two unit tests in signup.test.js.A reviewer comments "Should +91 prefixes be allowed?". You update the code, commit, and push again to the same branch. The PR updates automatically. After approval and green checks, it is merged.
How it works
- Branch from the latest
main. - Commit small, focused changes with clear messages.
- Push the branch and open the PR, linking the issue or ticket.
- CI runs: tests, build, lint. Fix anything red before asking for review.
- Review: reviewers comment, request changes, or approve.
- Update: push new commits to address comments; reply to each comment.
- Merge: using a merge commit, squash, or rebase, as the team prefers.
- Clean up: delete the branch.
In open source, you first fork the repository to your own account, push to your fork, and open the PR against the original project.
Real-world use
Almost every company runs this flow, on GitHub, GitLab, Bitbucket or Azure DevOps. Branch protection rules usually require at least one approval and passing checks before merging. Contributing PRs to open-source projects, even small documentation fixes, is also a good way for freshers to show real collaboration on their resume.
Common mistakes
- Opening one huge PR with 40 files and three unrelated changes. Reviewers cannot review it well. Keep PRs small.
- An empty description, or just "fixed bug". Explain what, why and how to test.
- Taking review comments personally or arguing. Reviews are about the code.
- Marking comments as resolved without changing anything or replying.
- Opening a new PR for every round of fixes. Push to the same branch.
What to say in the interview
"A pull request is how I propose merging my branch into main. I create a branch from the latest main, make focused commits, push it, and open a PR with a description of what changed, why, and how to test it. CI runs the tests automatically, and teammates review the diff and leave comments. I address the feedback by pushing more commits to the same branch. Once it is approved and checks pass, it is merged, usually with squash, and the branch is deleted. It keeps main stable and spreads knowledge across the team."
Follow-up questions
- What is the difference between squash merge, rebase merge and a merge commit?
- What do you look for when you review someone else's code?
- What is a draft pull request?
- How is a fork different from a branch?
Go deeper
Read these once the basics above feel easy.
When reviewing, check in this order: does it solve the stated problem, is it correct for edge cases, are there tests, is it readable, and is there any security risk such as unvalidated input or a hard-coded secret. Style nitpicks should be left to linters and formatters. Write comments as questions or suggestions ("What happens if the list is empty?") rather than commands.