Reading conflict markers in Git - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Identify the conflict content from Git conflict markers

Given the following conflict markers in a file after a merge conflict, what is the content from the current branch (HEAD)?

<<<<<<< HEAD
Line A
=======
Line B
>>>>>>> feature-branch

Git

<<<<<<< HEAD
Line A
=======
Line B
>>>>>>> feature-branch

A No content, conflict markers only

B Line A

C Line A and Line B combined

D Line B

💡 Hint

The content between <<<<<<< HEAD and ======= is from the current branch.

In Git conflict markers, the section between <<<<<<< HEAD and ======= shows the current branch's content. The section after ======= until >>>>>>> shows the incoming branch's content.

💻 Command Output

intermediate

What does Git show after a merge conflict?

After running git merge feature, you see conflict markers in a file:

<<<<<<< HEAD
int x = 5;
=======
int x = 10;
>>>>>>> feature

What does this indicate?

Git

git merge feature

A The feature branch was deleted

B The merge was successful with no conflicts

C The file has conflicting changes between current branch and feature branch

D The file was unchanged

💡 Hint

Conflict markers appear only when Git cannot automatically merge changes.

Git shows conflict markers when it cannot merge changes automatically. The markers highlight the conflicting sections from each branch.

❓ Troubleshoot

advanced

Resolving conflicts with multiple conflict markers

You see this in a file after a merge:

<<<<<<< HEAD
Line 1
=======
Line 1 modified
>>>>>>> feature

Some other text

<<<<<<< HEAD
Line 2
=======
Line 2 modified
>>>>>>> feature

What is the correct way to resolve these conflicts?

Git

<<<<<<< HEAD
Line 1
=======
Line 1 modified
>>>>>>> feature

Some other text

<<<<<<< HEAD
Line 2
=======
Line 2 modified
>>>>>>> feature

A Edit each conflict section to choose or combine changes, then remove all conflict markers

B Delete the entire file and recreate it

C Ignore the conflict markers and commit the file as is

D Run 'git reset --hard' to discard all changes

💡 Hint

You must manually fix each conflict section and remove markers before committing.

Each conflict section must be resolved by choosing or combining changes. After editing, all conflict markers must be removed to finalize the merge.

✅ Best Practice

advanced

Best practice to avoid long conflict markers in files

Which practice helps reduce the chance of large conflict markers appearing in files during merges?

A Always delete conflicting files and recreate them

B Avoid committing code for long periods

C Use only one branch for all development

D Commit small, frequent changes and pull updates often

💡 Hint

Frequent syncing helps keep branches aligned.

Small, frequent commits and regularly pulling changes reduce divergence, minimizing conflicts and large conflict markers.

🧠 Conceptual

expert

Understanding nested conflict markers in Git

Is it possible for Git to produce nested conflict markers (conflict markers inside conflict markers) in a file after a merge? Why or why not?

A Yes, but only if manual edits introduce nested markers

B Yes, Git can nest conflict markers if multiple merges overlap

C No, Git never nests conflict markers; each conflict is separate and flat

D No, Git removes all conflict markers automatically

💡 Hint

Think about how conflict markers are generated and edited.

Git itself does not produce nested conflict markers. Nested markers can appear only if a user manually edits a conflicted file and adds markers inside existing ones.

Practice

1. What do conflict markers in a Git file indicate?

easy

A. They show where changes from different branches clash in the file.

B. They mark lines that are deleted permanently.

C. They highlight syntax errors in the code.

D. They indicate lines that are ignored by Git.

Solution

1. Step 1: Understand the purpose of conflict markers

   Conflict markers appear when Git cannot automatically merge changes from different branches.

2. Step 2: Identify what conflict markers show

   They highlight the exact lines where changes from two sources conflict, so you can decide how to fix them.

3. Final Answer:

   They show where changes from different branches clash in the file. -> Option A

4. Quick Check:

   Conflict markers = show clashes [OK]

Hint: Conflict markers always show merge clashes in files [OK]

Common Mistakes:

• Thinking conflict markers show deleted lines
• Confusing conflict markers with syntax errors
• Believing conflict markers mark ignored lines

2. Which of the following is the correct way conflict markers appear in a Git file?

easy

A. >>>>>> HEAD
Your changes here
======
Incoming changes here
<<<<<<< branch-name

B. <<<<<<< HEAD
Your changes here
=======
Incoming changes here
>>>>>>> branch-name

C. <<<<<<< branch-name
Incoming changes here
=======
Your changes here
>>>>>>> HEAD

D. ======
Your changes here
<<<<<<< HEAD
Incoming changes here
>>>>>>> branch-name

Solution

1. Step 1: Recall the standard conflict marker format

   Git uses <<<<<<< HEAD to start your changes, ======= to separate, and >>>>>>> branch-name to end.

2. Step 2: Match the correct sequence

   <<<<<<< HEAD Your changes here ======= Incoming changes here >>>>>>> branch-name matches this exact format with your changes first, separator, then incoming changes.

3. Final Answer:

   <<<<<<< HEAD Your changes here ======= Incoming changes here >>>>>>> branch-name -> Option B

4. Quick Check:

   Conflict markers start with <<<<<<< HEAD [OK]

Hint: Conflict markers start with <<<<<<< HEAD and end with >>>>>>> branch-name [OK]

Common Mistakes:

• Swapping HEAD and branch-name positions
• Using wrong number of < or > symbols
• Mixing up the order of your and incoming changes

3. Given this conflict marker snippet in a file:

<<<<<<< HEAD
int x = 5;
=======
int x = 10;
>>>>>>> feature-branch

What will be the value of x after you manually choose the incoming change and save?

medium

A. 15

B. 5

C. 10

D. Conflict remains, no value assigned

Solution

1. Step 1: Identify the incoming change section

   The incoming change is after the ======= marker, which is int x = 10;.

2. Step 2: Understand manual conflict resolution

   Choosing the incoming change means keeping int x = 10; and removing conflict markers.

3. Final Answer:

   10 -> Option C

4. Quick Check:

   Incoming change value = 10 [OK]

Hint: Incoming changes are after ======= marker [OK]

Common Mistakes:

• Choosing the code before ======= instead of after
• Leaving conflict markers in the file
• Assuming both values apply simultaneously

4. You see this conflict marker in your file:

<<<<<<< HEAD
console.log('Hello');
=======
console.log('Hi');
>>>>>>> update-branch

After editing, you accidentally leave the conflict markers in the file and commit. What problem will this cause?

medium

A. The conflict markers will be ignored and code runs fine.

B. Git will automatically fix the conflict on next pull.

C. Git will delete the file on next merge.

D. The code will have syntax errors and may not run.

Solution

1. Step 1: Understand what conflict markers are

   Conflict markers are not valid code; they are special symbols for humans to resolve conflicts.

2. Step 2: Effect of leaving markers in code

   If left in the file, the code will have syntax errors and likely fail to run or compile.

3. Final Answer:

   The code will have syntax errors and may not run. -> Option D

4. Quick Check:

   Leaving markers = syntax errors [OK]

Hint: Remove conflict markers before committing to avoid errors [OK]

Common Mistakes:

• Assuming Git fixes conflicts automatically after commit
• Thinking conflict markers are comments
• Believing code runs fine with markers present

5. You have this conflict in a file:

<<<<<<< HEAD
function greet() {
  return 'Hello';
}
=======
function greet() {
  return 'Hi';
}
>>>>>>> feature

You want to combine both greetings so the function returns both messages separated by a comma. How should you edit the file to resolve the conflict correctly?

hard

A. Replace the conflict markers with:
function greet() {
return 'Hello, Hi';
}

B. Keep only the HEAD version:
function greet() {
return 'Hello';
}

C. Keep only the feature version:
function greet() {
return 'Hi';
}

D. Leave the conflict markers and both versions as is.

Solution

1. Step 1: Understand the goal to combine greetings

   You want the function to return both messages, so you must merge the changes manually.

2. Step 2: Edit the file by removing conflict markers and combining lines

   Replace the conflict markers and both versions with a single function returning 'Hello, Hi'.

3. Final Answer:

   Replace the conflict markers with: function greet() { return 'Hello, Hi'; } -> Option A

4. Quick Check:

   Combine changes by editing and removing markers [OK]

Hint: Edit conflict markers out and combine code as needed before commit [OK]

Common Mistakes:

• Leaving conflict markers in the file
• Choosing only one version without combining
• Not saving changes before committing