DevOps / Gitlab Interview questions
How does a GitLab merge request differ from a GitHub pull request?
Functionally, a GitLab merge request (MR) and a GitHub pull request (PR) do the same job: they propose merging one branch into another and provide a place for review and discussion. The differences are mostly in workflow depth and what's built in versus bolted on.
| GitLab Merge Request | GitHub Pull Request |
| Native approval rules (required approver count, Code Owners) built in. | Requires branch protection rules configured separately; approvals are simpler by default. |
| Pipeline status from native CI/CD shown directly on the MR. | Status checks come from GitHub Actions or third-party CI integrations. |
| Supports merge trains for queuing multiple MRs safely. | No native equivalent; relies on third-party apps like Mergify. |
| Draft MRs use a "Draft:" prefix. | Draft PRs use a distinct "Draft pull request" state. |
In short, an MR tends to carry more governance out of the box, since GitLab treats code review, CI status, and approval policy as one integrated feature rather than review plus separately configured checks.
Which feature is native to GitLab MRs with no third-party app needed?
On GitHub, CI status checks on a PR typically come from:
More Related questions...
