← back to the section

A pull request (in GitLab — merge request) is a proposal to merge your branch into the main one, formalized on the server: with a description, discussion, automated checks, and a merge button. Team quality control is built around the PR: other people's eyes (code review) and automation (the CI pipeline) look at the change before it lands in the shared code.

The PR lifecycle

  1. You push a branch → open a PR "my branch → main".
  2. Automation runs the build, tests, linters; colleagues read the code and leave comments.
  3. You make fixes: new commits to the same branch automatically appear in the PR.
  4. Approval (approve) → merge → the branch is deleted.

Not ready yet, but you need early feedback — open a draft PR: discussion is already possible, the merge button is locked.

Writing it up: respect for the reader's time

The reviewer has to understand your change without your context. Help them:

  • Title — what the PR does, in one line (often with the ticket number): "PROJ-142: export orders to CSV".
  • Description — what changed and why, how to verify; screenshots for UI. A link to the ticket is mandatory.
  • Size — the main factor in review quality. A 200-line PR gets read carefully; a 2000-line one gets "approved by eye". Cut a big task into a chain of small PRs.
  • Self-review: before assigning reviewers, walk through the changes tab yourself. A forgotten debug print, commented-out code, a stray file — cheaper to catch on your own.

How to get through review

Comments on the code are not a judgment of you; they are a second layer of the same quality control as tests. Working habits:

  • Respond to every comment: fixed it — "done" (plus a commit); disagree — make your case. A silently ignored comment = lost trust.
  • If you disagree — discuss, don't bulldoze. Two rounds of back-and-forth without converging is a cue to hop on a call: things get settled in minutes by voice.
  • Fixes go in as new commits, not rewrites: the reviewer needs to see what changed after their comments. You can tidy up the history right before merging.
  • Check the pipeline is green before assigning reviewers: asking people to read code that doesn't build is impolite.

Reviewing in the other direction is a skill too: comment on the code, not the author ("the error gets lost here", not "you lost the error"), suggest rather than command, point out the good parts.

Three ways to merge

The merge button usually offers a choice:

  • Merge commit — the branch's entire history is merged as is, plus a merge commit. A full chronicle, but main gets overgrown with small "wip" commits.
  • Squash and merge — all the branch's commits are collapsed into one tidy commit. Main stays clean: one task = one commit. The most common team choice.
  • Rebase and merge — the branch's commits are moved onto main one by one, without a merge commit: a straight line of history.

Which to pick is a team agreement from the branching model. A practical consequence of squash: don't polish intermediate branch commits beyond reason — only one will land in main anyway.

In short

  • PR = branch + description + discussion + automated checks + merge button. Draft — for early feedback.
  • A small PR with a clear "what and why" description is half the review quality. Self-review the diff before assigning reviewers.
  • Respond to every comment; make fixes as new commits; arguments longer than two rounds — take them to voice.
  • Merging: merge (chronicle), squash (task = commit, most common), rebase (straight line) — per team agreement.
  • Branching models — how the PR fits into the team's process.
  • Rebase and cherry-pick — tidying up branch history before merging.
  • The CI/CD pipeline — the automated checks that run on every PR.