Module 4 Lesson 5: Handling merge conflicts

Conflicts are the number one source of anxiety for new Git users. But once you understand what they are, they become just another part of the development process.

A Merge Conflict occurs when Git cannot automatically determine which version of a file to keep. This usually happens when the same line of the same file has been changed in two different ways on two different branches.

---

1. How a Conflict Starts

Imagine you have a file config.js:

• In main, someone changed line 5 to: const port = 8080;
• In feature-ui, you changed line 5 to: const port = 3000;

When you try to merge feature-ui into main, Git will stop and say: "CONFLICT (content): Merge conflict in config.js. Automatic merge failed; fix conflicts and then commit the result."

---

2. Reading Conflict Markers

When a conflict happens, Git modifies your files to show you exactly where the problem is. It adds "Markers" like this:

<<<<<<< HEAD
const port = 8080;
=======
const port = 3000;
>>>>>>> feature-ui

Breakdown of the markers:

• <<<<<<< HEAD: Everything below this line is what is currently in your "receiving" branch (e.g., main).
• =======: This is the divider.
• >>>>>>> feature-ui: Everything above this line is what is coming from the branch you are trying to merge.

---

3. The Resolution Process

To resolve a conflict, you must manually edit the file to choose the "winner" (or combine both).

Step 1: Open the file

Decide what the code should actually look like. Erase the markers (<<<<, ====, >>>>) and the rejected code.

Step 2: Save and Stage

Once the file looks correct, tell Git that you have resolved the issue:

git add config.js

Step 3: Complete the Merge

Finish the transaction:

git commit

Git will automatically provide a commit message like "Merge branch 'feature-ui' into main".

graph TD
    Merge["git merge feature-x"] --> Conflict{"Conflict Detected?"}
    Conflict -- "No" --> Success["Auto-Merge Complete"]
    Conflict -- "Yes" --> Mark["Markers Added to File"]
    Mark --> Edit["User Edits File (Manual Resolve)"]
    Edit --> Add["git add (Mark Resolved)"]
    Add --> Commit["git commit (Finalize)"]

---

5. Tips for Easier Merges

• Communicate: If you know a teammate is working on a specific core file, talk to them before you start changing it too.
• Merge Often: Don't wait three weeks to merge your feature. Small, frequent merges result in smaller, easier-to-fix conflicts.
• Use a Merge Tool: Modern editors like VS Code have a built-in "Conflict Navigator" with buttons like "Accept Current Change" or "Accept Incoming Change." This is much easier than manually deleting text markers.

---

Module 4 Comprehensive Practice Exercises

Let's simulate a real-world branching and conflict scenario:

1. Branching: Create two branches from main: branch-left and branch-right.
2. First Change: Switch to branch-left, change the first line of a file, and commit.
3. Competing Change: Switch to branch-right, change the same first line to something else, and commit.
4. The First Merge: Switch back to main. Merge branch-left. This should be a fast-forward merge.
5. The Conflict: Now, try to merge branch-right.
6. The Resolve:
   • Observe the conflict markers.
   • Edit the file so it contains both changes or a new combined version.
   • Stage and commit the resolution.
7. Verify: Run git log --graph --oneline. You should see a clear "diamond" shape in your history!

Checkpoint: If you successfully resolved the conflict and saw the merge commit in your log, you have officially passed the most difficult hurdle in Git!

---

Summary

In this lesson, we established:

• Conflicts happen when Git can't decide which change is the "correct" one.
• Git uses <<<<, ====, and >>>> markers to show the two versions.
• Resolving a conflict requires manual editing, staging, and a final merge commit.

Module Complete! You are now a master of the branch and merge workflow.

Next Module: We’ll move beyond your local computer and learn how to sync your work with others in Module 5: Remote Repositories.