Pull Requests and Code Review

Your friend has finished the new menu layout on a branch. Should they just merge it into main themselves? On a real team, almost never. Someone else reads the change first, automated checks run, and only then does it go in. On GitHub this is a pull request; on GitLab the same idea is called a merge request.

The rule

Propose on a branch, discuss, check, then merge into main.

The flow looks the same on both services:

1. Branch and commit. Work on a branch such as new-menu-layout, never directly on main.
2. Push the branch. git push -u origin new-menu-layout puts it on the remote.
3. Open the request. On the website, ask to merge new-menu-layout into main. Give it a clear title and a description: what changed, why, and how to check it (for example, "Open the menu page on a phone; cards should stack in one column").
4. Review. Teammates read the changes line by line, leave comments, ask questions and suggest improvements. Reviewers either approve or request changes.
5. Checks. Automated jobs can run on every request, such as tests, a linter or a preview build of the site. A red check blocks the merge until it is fixed.
6. Update. To answer feedback, commit more fixes to the same branch and push. The request updates itself; there is no need to open a new one.
7. Merge. Once approved and green, someone merges. The branch can then be deleted.

Teams often protect main so that changes cannot be pushed to it directly. Every change must come through a reviewed request.

Small is kind. A request that changes 40 lines gets a careful review within an hour. One that changes 2,000 lines gets skimmed or ignored for a week. Split big work into a series of small, focused requests.

Reviewing well means commenting on the code, not the person: "This selector also matches the footer links; could we scope it to .menu?" rather than "This is wrong." Point out the good parts too.

The shortcut

Before opening a request, write its description as if the reviewer knows nothing: What changed? Why? How do I see it working? If you cannot answer the three in a few lines, the request is probably too big or not ready.

Drills

Answer fast — trust the rule.

Remember

• Propose on a branch, discuss, check, then merge into main.
• Describe it for a reviewer who knows nothing: what, why, how to see it.
• Trap: huge requests get skimmed; small ones get real reviews.