Merge conflicts — a fifteen-minute clinic

ISOM 472 — Fall 2026/2027

Dr. Mohammad AlMarzouq Week 4

ISOM 472: Project in IS — Kuwait University

What a conflict is

  • Two branches changed the same lines
  • Git cannot choose which version is right
  • So a person decides — that person is you
  • Normal, not an error, and not a sign anything broke
ISOM 472: Project in IS — Kuwait University

Why it happened to you

  • A branch left open for days, drifting from main
  • Several people editing the same file, same rows
  • A branch that fell behind before review

team-agreement.md is the repeat offender — one table, everyone's row.

ISOM 472: Project in IS — Kuwait University

Prevention — the cheap part

  • Small pull requests, one story per branch
  • Update your branch from main before requesting review
  • Merge reviewed pull requests promptly
  • Agree, out loud, who edits a shared file

GitHub Desktop: Branch → Update from main. Website: the Update branch button on the pull request.

ISOM 472: Project in IS — Kuwait University

What the markers look like

<<<<<<< HEAD
| Ali  | Data Lead | Schema and RLS |
=======
| Ali  | Data Lead | Schema, RLS, and seed data |
>>>>>>> main

Everything between the two outer lines is both versions, stacked.

ISOM 472: Project in IS — Kuwait University

Resolving on the GitHub website

  • The "Resolve conflicts" button on the pull request
  • Edit down to the one correct final text
  • Delete all three marker lines
  • "Mark as resolved", then commit the merge

Only for simple text conflicts — one file, no code logic either side.

ISOM 472: Project in IS — Kuwait University

Resolving in GitHub Desktop

  • After Update from main, Desktop lists the conflicted files
  • Open the file in Antigravity — fix it, remove the markers
  • Back in Desktop: commit the merge, then push
ISOM 472: Project in IS — Kuwait University

Using the agent to help

  • Ask it to explain both sides, then propose merged text
  • Read the result yourself before accepting it
  • It must not "fix" a conflict by deleting a teammate's work
  • The reviewer checks the resolved file too
ISOM 472: Project in IS — Kuwait University

After resolving

  • Re-open or re-run the page to see it working
  • The pull request returns to review if the ruleset requires it
  • The reviewer reads the resolution commit specifically
ISOM 472: Project in IS — Kuwait University

Live — resolving one, now

  • isom472-fall2026/example-team
  • Two prepared branches, same line, same file
  • Watch each step — then Phase 2 begins
ISOM 472: Project in IS — Kuwait University

A conflict is a conversation between two teammates that Git cannot have for you.

ISOM 472: Project in IS — Kuwait University

The next hour — five teams, twelve minutes each

Minute On the screen — your repository at the tag, not slides Who
0–1 docs/delivery-notes/phase-2.md, heading 1: what was decided Phase Lead
1–3 docs/personas.md, then three stories with their criteria, one pair that share data Client Lead
3–5 docs/schema.md, with db/schema.sql beside it; one policy explained in words Data Lead
5–6 Heading 2: who wrote what, who builds what in Phase 3 Phase Lead
6–7 docs/finops-ledger.md: the plan's five lines, one Phase 2 row FinOps Lead
7–8 Heading 5: not finished, and where it went; the tag page Phase Lead
8–12 Questions from the room — the member whose area it is answers everyone

Every member speaks at least once. Each team asks at least one question of another team. Over time costs your question time, not the next team's.

ISOM 472: Project in IS — Kuwait University

Every sprint is read the same way

Read Evidence
It runs at the public address, the stories accepted this sprint can be done by a stranger
It was reviewed a sample of pull requests: the review says what was run, read, clicked; the approver merged
The board is true board, issues and git log agree; delivery note; tag
The Client Lead accepted criteria ticked in the issue; at least one story sent back
The ledger present, current, plausible — binary
Your own your stories shown running; the quiz that follows the sprint, answered on your phone in class
ISOM 472: Project in IS — Kuwait University

Now — Phase 2 delivery

ISOM 472: Project in IS — Kuwait University

The second class of week 4. This is a fifteen-minute opener before the main event: whole-class Phase 2 delivery, five teams presenting, twelve minutes each (format slide at the end of this deck). Several teams have already hit a conflict in real life — multiple members editing the same rows of docs/team-agreement.md on separate branches at once, and a run of "Merge branch 'main' into …" commits. This clinic exists because of that, not as a hypothetical.

Say this plainly at the start so the room relaxes: nobody did anything wrong by causing a conflict. It means two people were both making real progress on the same file at the same time.

Name the pattern, not the team: several people editing that one table on separate branches at once is exactly what produced this semester's conflicts. No team named here or on any slide in this deck.

This is the same habit from the roles deck's mistakes slide, update from main before review — today is what happens when the habit was skipped. Updating from main before review means the reviewer reads what will actually land, and conflicts surface while the branch is still small.

Point at each line: HEAD is your branch's version, the line of equal signs is the split, main is what is already merged. All three marker lines get deleted — none of them are real file content.

GitHub's web conflict editor changes its labels from time to time; follow what the page shows. If the button is not offered, the conflict is not simple text and belongs in GitHub Desktop instead.

This is the path for anything beyond a single simple line — most of what the room will actually meet. Antigravity opens the same file Desktop is pointing at; nothing needs re-locating.

An agent proposing a merge is a draft, not a decision. The failure mode to name out loud: an agent that silently keeps its own branch's version and drops the teammate's row entirely, without saying so.

The ruleset already requires one approving review before main, and nobody approves their own — a resolved conflict does not skip that gate. The reviewer is checking the merge itself, not just the original change.

Do this live in the browser, on the projector, before switching to presentations. Two branches were prepared in advance editing the same row of team-agreement.md so the conflict is guaranteed and small. Keep this under three minutes — the room is here for Phase 2.

Close the clinic here. The tool did not fail; it is handing a decision to the two people who made it, because it cannot make that call itself.

Order: team 1 to team 5 by number unless drawn at the start; the first team was told in the previous class. Keep time strictly — 60 minutes for five teams leaves no slack. A team of four spreads the rows; at four the Phase Lead carries the ledger row. The format is on the course site under the deliverables page and is reused at every delivery.

One slide, no numbers. The same rubric is used for Phase 3, 4, 5 and the Phase 6 sprint — say that, so it is heard as a standing rule. Full text on the course site, deliverables page. Then hand off to the first team.

Five teams present, whole class. Hand off to the first team.