Practice Git Merge Conflicts and Rebase in Your Browser

About this tutorial

Updated 2026-10-22

How to read conflict markers

Git writes three kinds of markers where it could not combine the edits. From <<<<<<< to ======= is one side, and from ======= to >>>>>>> is the other. You do not have to pick one side. You can rewrite it to keep both. Then delete the three marker lines and run git add.

    <h1>Leaf &amp; Loaf</h1>
<<<<<<< HEAD
    <p class="tagline">Spring sale: 20% off all bread</p>
=======
    <p class="tagline">Fresh bread every morning, from 7am</p>
>>>>>>> main
  </header>

Rebase replays your commits one by one on top of main, so HEAD is the main side and the sides are flipped compared with merge.

Lessons and steps

1. 1. Cause a conflict and read the situation

   On the feature/sale branch, you changed the site tagline to announce a sale. Meanwhile, a teammate added the opening time to the same line on main. When you bring main in, Git cannot combine two edits to the same line by itself, so you get a conflict.

   1. Run git log --oneline --graph --all to see how the two branches split.
   2. Bring main into feature/sale with git merge main. You will see CONFLICT.
   3. Run git status to see which file collided. Under Unmerged paths it says both modified: index.html.

2. 2. Read the markers, fix the file, finish the merge

   Git wrote markers where the edits collided. From <<<<<<< HEAD to ======= is your change, and from ======= to >>>>>>> main is the change on main. Rewrite it the way you want, delete the markers, tell Git it is fixed with git add, then commit to finish the merge.

   1. Click index.html in the file list on the left to open it in the editor. You will see two lines between three markers.
   2. Keep both the sale and the opening time. For example, keep the opening time line, add the sale as a <p class="sale"> line below it, and delete the three marker lines. Save with Ctrl+S (⌘+S on a Mac).
   3. Tell Git the file is fixed with git add index.html.
   4. Commit with a message to finish the merge: git commit -m "Merge main into feature/sale".
   5. Run git log --oneline --graph and check that the two lines meet in one commit.

3. 3. Abort the merge and go back

   You merged main again and hit the same conflict. When you are not sure how to fix it, or want to talk to your teammate first, you can abort the merge and go back to before it.

   1. Abort the merge with git merge --abort.
   2. Run git status and check you are back to before the merge (nothing to commit, working tree clean).

4. 4. Rebase onto the latest main

   Instead of merging, rebase replays your commits one by one on top of the latest main, so the history stays in a straight line. If a commit hits the same line, rebase stops at that commit. You fix it the same way as with merge, but you finish with git rebase --continue instead of git commit.

   1. Replay the two commits on feature/sale on top of main with git rebase main. It stops at the first one.
   2. Check with git status. It shows you are in the middle of a rebase, which commits are done and left, and the file that collided.
   3. Open index.html, keep both changes and save (Ctrl+S or ⌘+S). In a rebase the sides are flipped compared with merge: the <<<<<<< HEAD side is main, and the >>>>>>> side is your commit.
   4. Mark it fixed with git add index.html.
   5. Continue with git rebase --continue. An editor opens with the original commit message, so save it as is with :wq. The remaining commit applies cleanly and the rebase finishes.
   6. Run git log --oneline --graph and check that your two commits now sit in a straight line on top of "Show opening time" from main.

5. 5. Abort the rebase and go back

   You rebased again and it stopped at the first commit. You can abort a rebase too. The branch goes back to the commit it was on before the rebase started.

   1. Abort the rebase with git rebase --abort.
   2. Run git log --oneline --graph --all and check that feature/sale is back where it was, still split off from main.

6. 6. Squash commits before you push (rebase -i)

   On feature/sale, after the commit that adds the sale banner, there is a typo fix and a work-in-progress commit. Before you open a pull request, squash them into one commit with git rebase -i. rebase -i rewrites history, so use it only on commits you have not pushed yet.

   1. Look at the three commits to squash with git log --oneline.
   2. Open the last three commits in the editor (Vim) with git rebase -i HEAD~3. They are listed oldest first, each with pick.
   3. Change pick to fixup on the second and third lines, then save with :wq. fixup means "fold into the commit above and drop my message". Use j to move down, cw to change the word, and Esc to go back.
   4. Run git log --oneline again and check that only the sale banner commit is left.

Commands used here

FAQ