Stage 5 - Resolving Merge Conflicts

task-service is now on main with a new feature branch merged. Another teammate starts work on the same area and updates the task list order in task-service.js differently. When both branches touch the same lines, merge conflict is expected.

Why Git stops instead of guessing

Git can combine independent changes automatically. But if two commits edited the same part of a file in different ways, there is no objective automatic choice. Imagine one teammate wants by priority, another wants by due date in the same line. Git shows both and asks you to decide.

Producing one real conflict in the sample project

From main, create docs/ordering.txt in your editor. If the docs folder does not exist yet, create it through Finder, File Explorer, or your IDE. Put one line in the file:

Sort tasks by due date

Save the file and commit this baseline:

git switch main
git add docs/ordering.txt
git commit -m "docs: define initial ordering policy"

Create branch A. In docs/ordering.txt, replace the line with:

Sort tasks by priority then due date

Save and commit the branch A change:

git switch -c feature/ordering-priority
git add docs/ordering.txt
git commit -m "feature: update ordering by priority"

Return to main, create branch B, and change the same file differently:

git switch main
git switch -c fix/order-wording

In docs/ordering.txt, replace the line with:

Sort tasks by urgency then due date

Save and commit the branch B change:

git add docs/ordering.txt
git commit -m "fix: align wording with support docs"

Now try to merge branch A into main from main:

git switch main
git merge feature/ordering-priority

Git will mark docs/ordering.txt as conflicted.

Resolving by reading intent

Open the file with conflict markers:

<<<<<<< HEAD
Sort tasks by urgency then due date
=======
Sort tasks by priority then due date
>>>>>>> feature/ordering-priority

You keep the line that matches current product intent, for example:

Sort tasks by priority then due date

Then:

git add docs/ordering.txt
git commit

Practical rules

• Do not choose one side blindly if both are from valid contributors.
• Resolve with behavior first, style second.
• Run tests or at least smoke run after every conflict resolution.

After resolution, the repository history remains valid and explicit.

Post-merge conflict routine

After resolving one conflict, write down the final decision in notes or PR description, and link it to a ticket or requirement. This avoids repeating the same debate on future changes in task-service.

A resolved conflict should be treated as technical debt payment: one commit now, cleaner branch history later.