luvv to helpDiscover the Best Free Online Tools
Topic 5 of 7

Handling Merge Conflicts

Learn Handling Merge Conflicts for free with explanations, exercises, and a quick test (for Data Visualization Engineer).

Published: December 28, 2025 | Updated: December 28, 2025

Table of Contents

Why this matters

Common mistakes and self-check

  • Leaving conflict markers in files.
    • Self-check: search your repo for <<<<<<< or >>>>>>> before committing.
  • Choosing an entire side when a blended solution is needed.
    • Self-check: reconsider business logic (e.g., currency vs USD standardization).
  • Forgetting the final step.
    • Merge needs git commit; rebase needs git rebase --continue.
  • Formatting churn causing avoidable conflicts.
    • Self-check: run formatters/pre-commit hooks before merging to normalize JSON/YAML/SQL style.
  • Merging generated/binary files.
    • Self-check: mark them in .gitattributes to avoid merge (e.g., use merge=ours for build artifacts).

Exercises

Mirror of the interactive exercises below. Do them locally in a scratch repo.

Exercise 1 — Resolve a SQL conflict by blending logic
  1. Initialize a repo; create models/revenue.sql with a simple SELECT and commit.
  2. Branch A (main): rename a column; commit.
  3. Branch B (feature): add new columns; commit.
  4. Merge feature into main; resolve conflict by combining columns thoughtfully.
  5. Stage and commit. Validate the SQL reads clearly.
  • Checklist:
    • Markers removed.
    • Column names consistent with team standards.
    • Final merge commit message explains the decision.
Exercise 2 — Take theirs for JSON layout, keep local theme/title
  1. Create dashboards/sales.json with theme, title, and layout; commit.
  2. On main: change layout; commit.
  3. On feature: change theme to dark and improve title; commit.
  4. Merge feature into main. Use git checkout --theirs to take layout, then re-apply your theme/title edits.
  5. Stage and commit with an explanatory message.
  • Checklist:
    • Valid JSON (no trailing commas, consistent quotes).
    • Layout from incoming branch, theme/title from yours.
    • No conflict markers left.

Practical projects

  • Team merge lab: Two teammates intentionally edit the same chart config and practice resolving 3 different conflict styles (take ours, take theirs, blend).
  • SQL refactor rollout: Rename a common dimension and handle the cascade of conflicts across 5 models, committing clear rationale at each resolution.
  • Repo hygiene: Add formatters and a .gitattributes file to reduce future conflicts; simulate before/after by running merges.

Mini challenge

You are merging a feature that adds fx_rate and currency into a dashboard while main renamed revenue to revenue_usd and changed widget order. Decide a resolution plan in 3 steps: which columns to keep/rename, which layout to choose, and one sentence commit message explaining why.

Possible approach
  • Columns: keep revenue_usd and include fx_rate, currency for context.
  • Layout: take theirs (latest) to minimize downstream surprises.
  • Commit msg: "Merge: standardize on revenue_usd; keep fx_rate/currency for display; adopt latest layout."

Learning path

  1. Practice reading and removing conflict markers quickly.
  2. Resolve conflicts in SQL, then JSON/YAML files.
  3. Handle rebase conflicts and continue/abort confidently.
  4. Add repo policies to prevent noisy conflicts (formatters, .gitattributes).
  5. Explain your merge decisions in clear commit messages.

Next steps

  • Adopt a branching model (e.g., trunk or short-lived feature branches).
  • Use code reviews to catch risky merges before they happen.
  • Automate formatting and validation with pre-commit and CI to reduce conflicts.
Tip: Reducing future conflicts
  • Keep PRs small and focused.
  • Pull/rebase frequently.
  • Normalize formatting for JSON/YAML/SQL.
  • Do not version build artifacts; mark binary/generated files in .gitattributes.

Quick test & progress: The quick test is available to everyone. Log in to save your progress; otherwise, you can still take it for practice.

Practice Exercises

2 exercises to complete

Instructions

  1. Init a scratch repo and create models/revenue.sql with:
    SELECT order_id, revenue, currency FROM fact_orders;
  2. Commit on main:
    git add . && git commit -m "baseline revenue model"
  3. Create and switch to feature:
    git checkout -b feature/add-usd-and-fx
    Edit file to:
    SELECT order_id, revenue_usd AS total_revenue_usd, fx_rate FROM fact_orders;
    Commit.
  4. Switch back to main and change file to:
    SELECT order_id, revenue AS total_revenue, currency FROM fact_orders;
    Commit.
  5. Merge feature into main:
    git merge feature/add-usd-and-fx
    Resolve the conflict by keeping revenue_usd, and also keeping currency and fx_rate. Remove markers.
  6. Stage and commit:
    git add models/revenue.sql && git commit -m "Resolve conflict: standardize USD; keep currency+fx_rate"
Expected Output
A clean commit on main with models/revenue.sql selecting order_id, revenue_usd (as total_revenue_usd), currency, and fx_rate; no conflict markers remain.

Handling Merge Conflicts — Quick Test

Test your knowledge with 10 questions. Pass with 70% or higher.

10 questions70% to pass
Release And Tagging BasicsCI Basics For Builds And Checks

Have questions about Handling Merge Conflicts?

AI Assistant

Ask questions about this tool