GitLab Tutorial
- 1. Introduction to GitLab
- 2. Architecture & Self-Hosting
- 3. Groups, Projects & Namespaces
- 4. Issue Tracking & Agile
- 5. GitLab CI/CD Basics
- 6. GitLab Runners & Executors
- 7. Environments & Deployments
- 8. Merge Requests & Code Review
- 9. GitLab Container Registry
- 10. Package & Infra Registry
- 11. Security & Compliance
- 12. Monitoring & Analytics (DORA)
- 13. GitLab Pages Hosting
- 14. APIs, Webhooks & Integrations
- 15. GitLab Workflow & Best Practices
8. Merge Requests & Code Review
While GitHub has Pull Requests, GitLab uses the term Merge Request (MR). The concept is identical: you are requesting to merge code modifications from a source branch (e.g., `feature-branch`) into a target branch (e.g., `main`). However, GitLab’s Merge Requests are highly advanced, supporting enterprise approval workflows, review suites, and security scans built directly into the comparison view.
Creating a Merge Request
When you push a new branch to GitLab, the command line output will print a direct URL link to create an MR. Once created, the MR acts as the collaborative command center for that code change.
Core Components of an MR
- Title & Description: Uses Markdown to detail what changes are proposed. Can reference issues (e.g., `Closes #45`) to link them.
- Assignee vs. Reviewer: The Assignee is the developer responsible for implementing and fixing the code. The Reviewer is the colleague responsible for auditing the changes.
- Commits & Changes: Side-by-side or inline diff viewing of files that were modified.
- Pipeline Status: Displays the real-time execution progress of the CI/CD pipeline running for this specific branch.
Merge Approval Rules (Enterprise Grade)
In production environments, you want to prevent single developers from pushing changes directly to your primary branches. GitLab allows you to configure Approval Rules under project settings:
- Code Owner Approvals: Automatically requires approvals from specific developers or teams depending on which files are modified (e.g., edits to `/database` require DBA approval).
- Minimum Approvers: Set rules requiring a minimum number of approvals (e.g. at least 2 Senior Developers must approve) before the "Merge" button is unlocked.
- Security Approvals: Blocks merges if pipelines detect new vulnerability risks unless approved by security team leads.
Understanding Merge Strategies
GitLab supports three main merge strategies under project settings:
| Strategy | How it handles history | Pros / Cons |
|---|---|---|
| Merge Commit | Creates a merge commit when joining branches. Preserves complete history. | Shows exactly when branches joined, but can result in a messy, cluttered history tree in active teams. |
| Fast-Forward Merge | Never creates a merge commit. Simply moves the target branch pointer forward. Requires a linear history. | Extremely clean linear history, but requires developers to constantly rebase their branches locally before merging. |
| Squash & Merge | Combines all commits in the feature branch into a single commit upon merging. | Keeps primary branches very clean. Removes messy temporary local commit messages. Highly popular. |
Resolving Merge Conflicts in UI
When two developers edit the same line of code, a conflict occurs. Unlike simple platforms where you must resolve conflicts locally using CLI Git commands, GitLab includes a Web-Based Conflict Editor. This allows you to select which changes to keep right inside the browser dashboard and execute the resolution immediately!
