We're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue.

This lesson's interactive features are locked, please to keep using them

Make the Conflict

Before we move on, I just want to remind you that it's not often that you'll be creating your own conflicts. We're doing so because you probably don't have any friends to practice with... I kid, but even if you do have many developer friends, let's just make all the changes ourselves so you don't need to bother them.

In the "real world," what happens most often is:

  1. You switch to a new branch, say fix_bug, which is a copy of main.
  2. While you're fixing the bug, someone else merges their changes into main.
  3. You fix the bug, and it so happens that you edited the same files (and lines) that the other person did.
  4. You open a Pull Request to merge (or rebase) fix_bug into main, then Git tells you there's a conflict.
  5. You resolve the conflict on your branch.
  6. You complete the Pull Request with the conflict resolved.

Assignment

git log --all --oneline

While you should get a conflict, you might also notice something... odd. This time, the HEAD pointer contains main's changes rather than banned's! That's because rebase checks out the source branch, in this case main, so it can then replay the changes from banned on top of it.

If you had merged main instead of using rebase, HEAD would still point to banned because git doesn't switch branches under-the-hood during a merge. However, you kinda need to think in reverse with rebase... --theirs represents the banned branch which, in reality, is usually "our" changes.

* (no branch, rebasing banned)
  banned
  main

Because you're in the middle of a rebase, you're in a special state called "detached HEAD." This is a temporary state that allows you to resolve the conflict before you continue the rebase.

Run and submit the CLI tests without resolving the conflict.