Getting Started with Git — Chapter 4 / 4
Resolving conflicts
Conflicts can feel scary. But they are completely normal. This chapter teaches you to understand them, read them, and resolve them calmly.
Why conflicts happen
Key term: conflict
A conflict happens when two branches have changed the same lines of the same file. Git does not know which version to keep. So it asks you to choose. It's like two people editing the same sentence in a shared document at the same time.
Complete guide on merge conflicts →Most of the time, Git merges automatically without any problem. A conflict only happens when the same lines were changed differently in both branches.
Conflicts are not errors. They are a sign that two people (or two branches) worked on the same part of the code. This is perfectly normal in a team project.
Think of it this way: two people are decorating the same room. One paints the wall blue. The other paints it green. Someone needs to decide which color stays. That someone is you.
Reading conflict markers
Key term: conflict markers
When a conflict happens, Git adds special lines to the file. These lines are called markers. They show you the two versions side by side. It's like a note that says: "Version A is this. Version B is that. You pick."
Here is what a conflict looks like inside a file:
<<<<<<< HEAD
The content from your current branch
=======
The content from the branch being merged
>>>>>>> feature/header
There are 3 markers to understand:
<<<<<<< HEAD
This is the start of the conflict. Everything between this line and the ======= comes from your branch (HEAD). It's the version you had before the merge.
=======
This is the separator. It divides the two versions. Everything below this line comes from the other branch.
>>>>>>> branch-name
This is the end of the conflict. It shows the name of the other branch. After this line, the file is normal again.
Resolving a conflict step by step
Resolving a conflict always follows the same 4 steps. Do not skip any step.
Find the conflicting files
Run git status. It will show you which files have conflicts.
$ git status
both modified: index.html
Open the file and read the markers
Look at the file to see the two versions. Read both versions carefully before deciding.
$ cat index.html
# Read the content with the conflict markers
Choose the final content
Remove all the markers. Keep the version you want. You can keep version A, version B, or a mix of both.
In the simulator, you can use this command:
$ echo "final content" > index.html
# Replace the file with the content you chose
Mark as resolved and commit
Tell Git the conflict is fixed by adding the file. Then create a commit.
$ git add index.html
$ git commit -m "Resolve merge conflict"
How to avoid conflicts
You cannot avoid all conflicts. But you can make them rare and small. Here are some good habits:
Make small, frequent commits
The fewer lines you change at once, the lower the risk of conflict. Commit often. Do not wait until you have changed 200 lines.
Merge main into your branch regularly
Do not let your branch get too far behind. Regularly bring in the latest changes from main. This way, small conflicts are caught early, when they are easy to fix.
Talk to your team
If you know someone else is working on the same file, talk to them. Simple communication prevents many conflicts.
Use small files
Split your code into many small files instead of one large file. If two people work on different small files, there is no conflict.
Further reading
Common mistakes
- ●Leaving the
<<<<<<<markers in the code. The file will not work if you leave them in. - ●Running
git add+git commitwithout actually fixing the conflict. Git will accept it, but the file will be broken. - ●Deleting the other person's content without reading it. Always read both versions first.
- ●Panicking and running
git merge --abortevery time. Conflicts are normal. Take a breath and resolve them.
Your feedback matters
Help us improve this course by sharing your thoughts.