In this lesson, you’ll learn how to interpret the specific visual indicators Git inserts into your source code when a merge conflict occurs, allowing you to manually resolve competing changes.
When you attempt to merge two branches that modified the same lines in a file, Git pauses the process and marks the file as "unmerged." If you open that file in your text editor, you will see special "conflict markers" that define exactly where the disagreement lies.
Understanding the Anatomy of a Conflict
Git uses these markers to wrap the conflicting code blocks. Here is how to read them:
<<<<<<< HEAD
print("Hello from the main branch")
=======
print("Hello from the feature branch")
>>>>>>> feature-branch
<<<<<<< HEAD: This marks the start of the changes from the branch you are currently on (the branch you performed themergeinto).=======: This is the "divider." Everything above this line is your current local state, and everything below it is the content coming from the branch you are trying to merge in.>>>>>>> feature-branch: This marks the end of the incoming changes from the branch namedfeature-branch.
How to Analyze Them
When you encounter these, don't panic! Your goal is to choose which code survives, or rewrite it to incorporate both ideas.
- Read the context: Look at the code above and below the markers to understand the intent of both changes.
- Make a decision: Delete the markers (
<<<<<<<,=======,>>>>>>>) and edit the code until it reflects the desired state. - Clean up: Ensure you have removed every single marker. If you leave even one, your code will contain syntax errors.
Once you have deleted the markers and saved your final, corrected version of the file, the conflict is considered "resolved." You can then proceed by staging the file with git add and completing the merge with a commit.
Key Takeaway: Conflict markers are Git’s way of saying "I don't know which version you prefer," and your job is to manually edit the file to remove the markers and finalize the content before committing.