GitLab 06 🦊 Resolving Merge Conflicts and Handling Code Reviews - KandZ

⏱️ Estimated read: 10 min | |

A merge conflict is not an error. It is a signal that two branches changed the same lines of the same file, and Git cannot decide which change to keep. The resolution is a human decision, made in the Git working tree, and then committed to the source branch. GitLab’s interface surfaces the conflict, offers a web-based editor for simple cases, and blocks the merge until the conflict is resolved. Code review is the second half of the merge request workflow: the structured evaluation of the proposed changes by a reviewer, with a decision that gates the merge. The exam tests both: how to resolve a conflict locally, how to resolve it in the GitLab web editor, and how to conduct a review that produces an approval or a request for changes.

Key point: A merge conflict is resolved by editing the conflicted files, removing the conflict markers, staging the resolved files, and committing. In GitLab, the conflict is displayed on the merge request’s “Overview” tab, and the web editor can resolve simple conflicts without a local checkout. The merge button is disabled until the conflict is resolved and the pipeline passes.

Why merge conflicts and code reviews exist

The concurrent edit problem. Two developers branch from main. Developer A changes line 10 of app.ts. Developer B also changes line 10 of app.ts. Both push their branches. The first merge succeeds. The second merge fails because Git cannot determine whether line 10 should be A’s version, B’s version, or a combination. The conflict is not a bug in Git—it is Git refusing to guess. The developer must inspect both changes and decide the correct outcome .

The review gate problem. A merge request that can be merged without review is a merge request that will eventually merge broken code. GitLab’s approval rules require a specified number of approvals before the merge button becomes active. The review is not a comment thread—it is a decision. “Approve” satisfies the requirement. “Request changes” blocks the merge until the feedback is addressed .

The pipeline gate problem. A merge request pipeline runs against the merged result of the source and target branches. If the pipeline fails, the merge is blocked. This catches integration failures that a local test suite cannot detect, because the local suite runs against the source branch alone . The reviewer should check the pipeline status before approving.

The conflict resolution problem. GitLab offers three paths for resolving a conflict. The web editor resolves simple conflicts (text files, no binary) without a local checkout. The local resolution uses git merge or git rebase on the developer’s machine. The “resolve conflicts” button in the MR opens a web-based editor for each conflicted file, with the conflict markers displayed and the ability to select “Use ours”, “Use theirs”, or edit manually .

The trade-off. Resolving conflicts locally gives the developer full control and the ability to run tests before committing. Resolving in the web editor is faster for simple conflicts but does not allow running the test suite. The local resolution is the recommended path for any conflict that touches logic; the web editor is sufficient for documentation or configuration changes.

a. Resolving conflicts locally

The conflict appears when the developer attempts to merge the target branch into the source branch, or when the source branch is rebased onto the target. The git status command shows the conflicted files.

# Update the source branch with the target branch
git checkout feature/login
git fetch origin
git merge origin/main
# CONFLICT (content): Merge conflict in src/app.ts

The conflicted file contains conflict markers. The section between <<<<<<< HEAD and ======= is the local version (the source branch). The section between ======= and >>>>>>> origin/main is the incoming version (the target branch).

<<<<<<< HEAD
const port = 3000;
=======
const port = 8080;
>>>>>>> origin/main

The developer edits the file to produce the correct final version, removes the conflict markers, and stages the resolved file.

# Edit the file to resolve
# Remove the markers and choose the correct content
git add src/app.ts
git commit -m "Resolve merge conflict in app.ts"
git push origin feature/login

The merge request updates automatically. The conflict indicator disappears, and the merge button is enabled if the pipeline passes and the approvals are satisfied.

b. Resolving conflicts in the GitLab web editor

For simple conflicts, the GitLab web editor is faster. The merge request’s “Overview” tab shows a “Resolve conflicts” button when a conflict exists. The button opens a list of conflicted files. Each file opens in a text editor with the conflict markers displayed and three buttons: “Use ours”, “Use theirs”, and “Edit inline”.

The “Use ours” option keeps the source branch’s version. The “Use theirs” option keeps the target branch’s version. The “Edit inline” option opens the file in an editable text area where the developer can combine the two versions manually. After editing, the “Commit to source branch” button commits the resolution to the source branch .

The web editor is limited to text files. Binary files, files with merge conflicts in submodules, and files that exceed the editor’s size limit cannot be resolved in the web editor. The local resolution is the only path for those cases.

c. Handling code reviews

The review process begins when a reviewer is assigned. The reviewer opens the merge request, reads the description, and selects the “Changes” tab to view the diff. The diff shows the added, removed, and modified lines. Comments are placed on specific lines.

The review has four decisions. “Start a review” collects comments without publishing them; the reviewer adds comments across multiple files and submits them all at once. “Approve” signals that the changes are ready to merge. “Request changes” blocks the merge until the feedback is addressed. “Comment” leaves feedback without a decision.

# Review flow
Changes tab → click line number → write comment
Start a review (collects comments)
Add more comments → Add to review
Submit your review → Approve or Request changes

The reviewer should check the pipeline status before approving. A red pipeline blocks the merge regardless of the approval. A green pipeline with warnings may still indicate a problem that the reviewer should address.

The author responds to a “Request changes” review by making the changes, pushing new commits to the source branch, and re-requesting a review. The reviewer’s previous approval is dismissed when new commits are pushed, which forces a fresh review of the updated code.

Complete Example Session

# ============================================
# PART 1: IDENTIFY THE CONFLICT
# ============================================

git checkout feature/login
git fetch origin
git merge origin/main
# CONFLICT (content): Merge conflict in src/app.ts

# ============================================
# PART 2: INSPECT THE CONFLICTED FILE
# ============================================

cat src/app.ts
# <<<<<<< HEAD
# const port = 3000;
# =======
# const port = 8080;
# >>>>>>> origin/main

# ============================================
# PART 3: RESOLVE THE CONFLICT
# ============================================

nano src/app.ts
# Replace the conflict block with:
# const port = 8080;
# (the target branch's value, or a combination)

# ============================================
# PART 4: STAGE AND COMMIT
# ============================================

git add src/app.ts
git commit -m "Resolve conflict in app.ts"
git push origin feature/login

# ============================================
# PART 5: VERIFY THE MR UPDATES
# ============================================

# GitLab → Merge request → Overview
# The conflict indicator is gone.
# The pipeline runs.

# ============================================
# PART 6: REVIEW THE MR
# ============================================

# Reviewer opens the MR.
# Selects "Changes" tab.
# Adds inline comment on line 42.
# Clicks "Start a review".

# ============================================
# PART 7: SUBMIT REVIEW
# ============================================

# Clicks "Submit your review".
# Selects "Request changes".
# Author must address the feedback.

# ============================================
# PART 8: AUTHOR RESPONDS
# ============================================

# Author pushes new commits.
# Re-requests review from the same reviewer.
# Reviewer approves.

# ============================================
# PART 9: MERGE
# ============================================

# With approval and pipeline green:
# Merge button is enabled.
# Click "Merge".

The nine parts trace the conflict resolution and review: identification, inspection, resolution, commit, MR update, review, request changes, author response, and merge.

Quick Reference

Conflict Resolution Commands

Command	Purpose
`git status`	Show conflicted files
`git merge <branch>`	Merge and reveal conflicts
`git rebase <branch>`	Rebase and reveal conflicts
`git add <file>`	Mark a conflict as resolved
`git commit`	Complete the merge
`git merge --abort`	Cancel the merge

Conflict Markers

Marker	Meaning
`<<<<<<< HEAD`	Start of local version
`=======`	Separator
`>>>>>>> branch`	End of incoming version

Review Decisions

Decision	Effect
Approve	Satisfies approval requirement
Request changes	Blocks merge
Comment	Feedback without decision

Best Practices

✅ Do This:

git merge origin/main
<!-- Resolve conflicts locally for logic changes -->   # ✅

# Use the web editor for simple conflicts
<!-- Documentation, config, no logic changes -->      # ❌ (but acceptable)

# Request changes when the code is not ready
<!-- The merge must be blocked until addressed -->    # ✅

❌ Don’t Do This:

# Accept "Use ours" or "Use theirs" blindly
<!-- The conflict requires a decision, not a default --> # ❌

# Approve without checking the pipeline
<!-- A red pipeline blocks the merge anyway -->       # ❌

# Ignore a "Request changes" review
<!-- The merge cannot proceed until addressed -->     # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Conflict not resolved	Markers left in the file	Remove markers, `git add`
Merge button disabled	Pipeline failing	Fix the failing job
Review comments not visible	Used “Comment” instead of “Start a review”	Submit the review
Approval dismissed	New commits pushed	Re-request review
Web editor cannot resolve	Binary file or submodule	Resolve locally

Real-World Examples

1. Start Merge

git merge origin/main

2. Abort Merge

git merge --abort

3. Resolve and Stage

git add src/app.ts

4. Complete Merge

git commit -m "Resolve conflict"

5. Web Editor

MR → Overview → Resolve conflicts → Edit inline

6. Inline Comment

Changes tab → click line → comment

7. Start Review

Changes tab → Start a review

8. Submit Approve

Submit your review → Approve

9. Submit Request Changes

Submit your review → Request changes

10. Re-request Review

MR → Reviewers → re-request icon

Visual

Conflict Resolution Flow

┌──────────────────────────────────────────────┐
│  git merge origin/main                       │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  CONFLICT in src/app.ts                      │
│  <<<<<<< HEAD                                │
│  =======                                     │
│  >>>>>>> origin/main                         │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Edit file, remove markers                   │
│  Choose the correct content                  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  git add src/app.ts                          │
│  git commit -m "Resolve conflict"            │
│  git push                                    │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  MR updates: conflict gone, pipeline runs    │
└──────────────────────────────────────────────┘

Review Decision

┌──────────────────────────────────────────────┐
│  Reviewer opens MR                           │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Reads Changes tab, leaves comments          │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Submit review                               │
│  ├─ Approve → merge enabled                  │
│  ├─ Request changes → merge blocked          │
│  └─ Comment → neutral                        │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Author addresses feedback                   │
│  Re-requests review                          │
└──────────────────────────────────────────────┘

Summary

Item	Value
Conflict markers	`<<<<<<<`, `=======`, `>>>>>>>`
Resolve locally	Edit, `git add`, `git commit`
Web editor	“Resolve conflicts” button on MR
Review decisions	Approve, Request changes, Comment
Approval dismissal	New commits reset approval
Re-request	Icon next to reviewer name
Merge gate	Approvals + passing pipeline

Key takeaways:

A merge conflict is a human decision. Git cannot guess which version is correct. The developer must inspect both sides and choose or combine them. The “Use ours” and “Use theirs” buttons are shortcuts, not substitutes for reading the conflict .
The local resolution is the primary path. It allows running the test suite before committing. The web editor is faster for simple conflicts but cannot run tests .
The review is a decision, not a comment. “Approve” satisfies the approval requirement. “Request changes” blocks the merge. “Comment” is neutral .
The pipeline is the second gate. A passing pipeline is required for the merge, regardless of the approval count. A red pipeline blocks the merge button.
Approvals are dismissed on new commits. The reviewer must re-approve after the author pushes changes. This ensures the approval reflects the current code, not an earlier version.

Remember: The merge conflict is resolved in the file, not in the merge request. The review is resolved in the merge request, not in the file. The conflict requires editing, staging, and committing. The review requires reading, commenting, and deciding. Both are gates between the source branch and the target branch. Both must be cleared before the merge.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!