What are merge requests in GitLab and how do they differ from pull requests?

Think of a merge request like a formal proposal at a city council meeting. A council member (developer) drafts a proposal (code changes on a branch), submits it for public review (opens an MR), other members ask questions and suggest amendments (code review comments), the proposal undergoes an impact assessment (CI/CD pipeline runs tests and security scans), the required committee chairs sign off (approvals), and finally the proposal is enacted into law (merged into the main branch). The entire debate is recorded in the minutes (MR history) for future reference.

A merge request in GitLab is created from a source branch targeting a destination branch. The MR page displays the diff of all changes, a discussion thread for general comments, the ability to leave inline comments on specific lines of code, the status of associated CI/CD pipelines, approval status, and links to related issues. Unlike GitHub pull requests, which were later enhanced with checks and review features, GitLab merge requests were designed from the start to integrate tightly with the CI/CD pipeline. The pipeline status is prominently displayed on the MR, and you can configure the project so that MRs cannot be merged unless the pipeline succeeds. GitLab also supports merge request pipelines, which are pipelines that run specifically in the context of the merge result, testing what the code will look like after merging rather than just the source branch in isolation.

Internally, when you create a merge request, GitLab stores it as a database record linking the source branch, target branch, author, description, and metadata. GitLab computes the diff between the source and target branches and renders it in the web interface. If the project has CI/CD configured, GitLab triggers a pipeline for the source branch (or a merged-result pipeline if configured). Reviewers can approve the MR, and GitLab tracks how many approvals have been given versus how many are required. The approval rules engine supports sophisticated policies: require two approvals from the backend team if backend files changed, require one approval from the security team if Dockerfile or dependency files changed. When all conditions are met (pipeline passed, approvals obtained, no unresolved discussions if that setting is enabled), the merge button becomes active.

In production, merge requests are the central workflow for teams using GitLab. A team working on auth-service would follow this pattern: a developer creates a branch like feature/oauth2-pkce-flow, pushes commits, and opens an MR targeting main. The MR description references the issue with Closes #187, linking the MR to the issue tracker. The pipeline runs lint, build, test, and security scan stages. Reviewers from the auth-team are automatically assigned based on CODEOWNERS rules (yes, GitLab has its own CODEOWNERS equivalent in the CODEOWNERS file). Merge trains allow multiple approved MRs to be queued and merged sequentially, with each MR tested against the combined result of all MRs ahead of it in the queue. This prevents the classic problem of two individually passing MRs that break when combined.

A common gotcha is confusing the terminology when interviewing at companies that use GitLab. Never call them 'pull requests' in a GitLab context; they are 'merge requests' and the distinction matters because it signals platform fluency. Another pitfall is not using merge request templates, which GitLab supports through .gitlab/merge_request_templates/ directory in your repository. Templates ensure developers provide context about their changes, testing performed, and deployment considerations. Without templates, MR descriptions tend to be empty or unhelpful, making code review less effective.