DevOps / Github Interview questions
How does a GitHub pull request differ from a GitLab merge request?
Both propose merging one branch into another with review attached, but GitHub PRs and GitLab MRs diverge in what's native versus what needs extra configuration or a third-party app.
| GitHub Pull Request | GitLab Merge Request |
| Required reviewers configured via branch protection settings. | Approval rules (count, Code Owners) configured directly on the MR/project settings. |
| Draft PRs use a distinct "Draft" state. | Draft MRs use a "Draft:" title prefix. |
| Merge queue available natively for serializing multiple PRs safely. | Merge trains serve the same purpose, GitLab's native equivalent. |
| Status checks come from Actions or any connected external CI. | Pipeline status comes from native GitLab CI/CD by default. |
The underlying idea, a reviewed diff gated by status checks and approvals before merging, is functionally the same on both platforms; the practical difference is mostly which pieces are native out of the box versus configured through separate settings or third-party integrations.
GitHub's feature for safely serializing multiple pull requests into main is called:
How does a draft state get indicated differently between the two platforms?
More Related questions...
