Merge Conflicts and Rebase

Introduction

When two branches change the same part of a file, Git cannot decide which version wins. That is a conflict. It sounds scary, but it is a normal part of teamwork, and there is a clear routine for it.

Anatomy of a conflict

After a conflicting merge, Git marks the file like this:

<<<<<<< HEAD
Welcome to our site
=======
Welcome to the Learn site
>>>>>>> feature-greeting

• Between <<<<<<< and ======= is your current branch's version.
• Between ======= and >>>>>>> is the incoming version.

Resolve it

1. Run git status to see which files are in conflict.
2. Open each file, decide the final text, and delete the marker lines. You can keep one side, the other, or combine them.
3. Test that the result still works.
4. Mark it resolved and finish:

git add greeting.txt
git commit

To give up, run git merge --abort and you are back to before the merge. Editors and tools such as VS Code show a friendly side-by-side view for the same job.

Merge versus rebase

Both combine work from one branch into another.

• Merge joins the histories with a merge commit. History shows exactly what happened, including the branching.
• Rebase takes your commits and replays them on top of another branch, producing a straight, linear history.

git switch feature
git rebase main

Now feature looks as if you started it from the latest main. Afterwards, merging into main can be a simple fast-forward.

Rebase creates new commits with new hashes, so it rewrites history. Conflicts can occur during a rebase too. Fix the file, run git add, then git rebase --continue. To cancel, run git rebase --abort.

The golden rule of rebasing

Do not rebase commits that you have already pushed and that others may have built on.

Rewriting shared history forces everyone else to untangle their copies. Rebase your own private branches, for example to tidy them before opening a pull request. Use merge for shared branches.

Which to choose?

• Want a faithful record? Merge.
• Want a clean, linear history before a pull request? Rebase your private branch.
• Many teams agree a rule, such as "rebase your feature branch on main, then merge with a pull request". Follow your team's choice.

Try it yourself

In a practice repository, create two branches that edit the same line of the same file. Merge them, create the conflict, resolve it and commit. Then try the same thing with a rebase and compare git log --oneline --graph.

Summary

• A conflict means two changes touched the same lines. Edit the file, git add, and commit.
• Merge keeps true history, and rebase replays commits for a linear history.
• Never rebase shared commits, only private ones.