Handling Conflicts And Collaboration

Why this matters

BI Developers work in teams on SQL models, data transformations, and BI assets (e.g., datasets, reports). Multiple people often touch the same files, which causes merge conflicts. Handling conflicts well prevents broken dashboards, protects data logic, and speeds up delivery. You will face this in real tasks like updating a shared metric, refactoring a model, or shipping a sprint of report changes.

• Real tasks: align a business metric across several SQL models; split a Power BI artifact; fix a hotfix without undoing a teammate’s work; revert a bad change quickly.
• Outcome: clean history, faster reviews, fewer regressions, and a calmer team.

Concept explained simply

Git tracks changes to files. A merge conflict happens when two branches change the same part of a file and Git cannot decide which change to keep. Git pauses and asks you to choose. That’s it.

Mental model

• Timeline: your branch and main branch are two timelines that must reconcile.
• Diff blocks: conflicts are just overlapping edited blocks that need a decision.
• Editor task: your job is to produce the best combined version, then mark it resolved.

Core collaboration flows

• Create a feature branch, make small commits.
• Sync often: fetch and rebase (or merge) main to reduce surprise conflicts.
• Open a pull request for review; keep the diff small and focused.
• Resolve conflicts locally; push the resolution.
• Merge via PR; if something goes wrong, revert quickly.

Typical conflict types in BI

• SQL logic conflicts: two people modify the same WHERE clause, JOIN, or CTE.
• YAML/JSON metadata conflicts: same model name, column description, or test definition changed.
• Migration script conflicts: conflicting ALTERs or duplicate migration numbers.
• Notebook or script conflicts: cell reordering or duplicated functions.
• Binary BI artifacts (e.g., .pbix): cannot be line-merged. Use coordination, project mode (text files), or locking strategies.

Conflict resolution playbook

1. Pause and understand: read both sides. What is each change trying to accomplish?
2. Reproduce context: run tests or preview queries to understand intended behavior.
3. Decide merge strategy: keep ours, keep theirs, or combine logically.
4. Edit carefully: remove conflict markers and produce a clean, working block.
5. Self-check: run SQL, unit/data tests, or validate report visuals.
6. Stage and continue: git add the files; then git commit (merge) or git rebase --continue (rebase).
7. Communicate: leave a PR note explaining your choice if non-obvious.

Worked examples

Example 1 — SQL metric conflict

Conflict markers:

SELECT user_id,
       SUM(CASE WHEN event_name = 'purchase' THEN amount ELSE 0 END) AS revenue
FROM fact_events
WHERE country IN ('US','CA')
<<<<<<< HEAD
  AND event_date >= '2024-01-01'
=======
  AND is_test_user = FALSE
>>>>>>> feature/anti-test-users
GROUP BY 1;

Resolution (combined intent: filter by date AND exclude test users):

SELECT user_id,
       SUM(CASE WHEN event_name = 'purchase' THEN amount ELSE 0 END) AS revenue
FROM fact_events
WHERE country IN ('US','CA')
  AND event_date >= '2024-01-01'
  AND is_test_user = FALSE
GROUP BY 1;

Then: git add file.sql; git commit -m "Resolve: metric filters include date and exclude test users"

Example 2 — YAML model metadata conflict

models:
  - name: dim_customer
    columns:
      - name: customer_id
<<<<<<< HEAD
        description: "Unique customer ID"
=======
        description: "Business key for customer"
>>>>>>> feature/marketing-defs

Resolution (merge wording and keep clarity):

models:
  - name: dim_customer
    columns:
      - name: customer_id
        description: "Unique customer ID (business key)"

Example 3 — Rebase conflict while updating branch

1. git fetch origin
2. git rebase origin/main
3. Git stops on conflict. Open files, resolve as shown above.
4. git add <files>
5. git rebase --continue
6. If stuck: git rebase --abort (to try again later) or pair with a teammate.

Bonus — Binary BI artifact (.pbix)

• You cannot merge .pbix line-by-line. Prefer project mode (text-based files) or avoid simultaneous edits.
• If binary must remain: agree on a single editor at a time; others branch off text components or wait. Optionally configure .gitattributes to avoid merge attempts.

# .gitattributes
*.pbix binary
# Optional (use with caution): always prefer main on merge
# *.pbix merge=ours

Note: If using a forced strategy like merge=ours, communicate clearly since one side is discarded.

Collaboration patterns that prevent conflicts

• Small PRs with one purpose.
• Rebase or merge from main daily when a branch lives longer than a day or two.
• Agree on file ownership for high-churn areas (e.g., core metrics, shared macros).
• Adopt PR templates: purpose, validation steps, risk, rollback plan.
• Use .gitignore and .gitattributes to control noise and binary behavior.
• Prefer text-based project formats for BI tools when available.
• Run automated checks (lint/tests) on PRs to catch regressions early.

Common mistakes and how to self-check

• Mistake: keeping only “yours” and dropping critical changes. Self-check: review the diff and PR conversation; run affected queries/reports.
• Mistake: resolving conflicts only syntactically, not logically. Self-check: validate business logic with sample data.
• Mistake: pushing large, mixed PRs. Self-check: split by topic; verify each commit message explains the why.
• Mistake: ignoring binary file coordination. Self-check: confirm who edits shared artifacts and when.
• Mistake: merging without a rollback plan. Self-check: know how to git revert quickly.

Exercises

Complete these hands-on tasks locally. They mirror the exercises below and help you practice conflict handling safely.

Exercise 1 — Resolve a SQL merge conflict

1. Create a repo with a file metrics/revenue.sql containing a baseline query.
2. Create branch feature/date-filter. Edit the file to add a date filter; commit.
3. Switch to main; edit the same lines to exclude test users; commit.
4. Merge feature/date-filter into main (or rebase feature/date-filter onto main) to trigger a conflict.
5. Open the file, resolve by combining both changes; run a quick SELECT on a small dataset if available.
6. Stage and commit. Explain your decision in the commit message.

Exercise 2 — Coordinate on a binary artifact

1. Add a placeholder binary file reports/SalesReport.pbix (or any binary like a zip) to simulate a BI artifact.
2. Add to .gitattributes: *.pbix binary
3. Decide a policy: one editor at a time. Create a small text file reports/SalesReport.NOTES.md where editors log who is working and when.
4. Simulate two branches trying to change the .pbix: demonstrate why you cannot merge and how the NOTES log prevents collision.
5. Finalize: keep one branch’s binary, communicate in NOTES.md what changed, and push.

Note: The quick test on this page is available to everyone. Only logged-in users will have their test progress saved.

Mini challenge

Two PRs touch the same core metric: one adds a country filter, the other changes the revenue calculation to exclude refunds. Draft a short plan to merge both safely: who to pair with, what validation to run, and how you’ll communicate the final behavior.

Who this is for

• BI Developers, Analytics Engineers, Data Analysts who collaborate in Git.
• Anyone contributing to shared SQL models or BI artifacts.

Prerequisites

• Basic Git: clone, branch, commit, push, pull.
• Comfort editing SQL/YAML files and running simple checks.
• Familiarity with your BI tool’s project structure.

Learning path

• Before: Branching strategies and commit hygiene.
• Now: Handling conflicts and collaboration.
• Next: Code review practices, CI checks, and safe releases.

Practical projects

• Team metric standardization: consolidate revenue logic across 3 models, resolve conflicts, and document the final definition.
• BI artifact split: convert a report to a text-based project (if supported) and show how it reduces conflicts.
• Introduce .gitattributes and PR template: measure conflict rates over two sprints before/after.

Next steps

• Apply the playbook to an active branch today.
• Pair on one tricky conflict to learn faster.
• Take the Quick Test below to check your understanding. If you’re logged in, your test progress will be saved.