Mastering the Git Rebase Screen

The screen goes black except for a block of terse commands and half-merged commits staring back at you. You’ve landed in the Git rebase screen.

This is where changes collide. Git stops and waits. The rebase screen shows each commit in conflict, along with markers inside the file. Your job is to resolve these conflicts before continuing.

When you run git rebase, Git takes commits from one branch and replays them onto another. If code changes overlap, Git cannot merge automatically. It drops you into the rebase screen—often inside your configured text editor, like Vim, Nano, or VS Code—so you can fix the problem.

At the top, you’ll often see a list of commits to edit, squash, or drop. During an interactive rebase (git rebase -i), each line lists a commit hash, the command, and the commit message. You can change these commands to control the rebase. pick keeps a commit. squash merges it into the previous commit. edit lets you change it before continuing.

Inside files, conflict markers appear as:

<<<<<<< HEAD
your changes here
=======
incoming changes here
>>>>>>> commit-hash

You must choose which code to keep—or merge both sets—then remove the markers. Save the file, run git add <file>, and then git rebase --continue.

If you need to skip a commit entirely, run git rebase --skip. To abort the whole operation and return to the original state, run git rebase --abort.

Mastering the Git rebase screen makes branch history cleaner and avoids merge clutter. It clarifies commit sequences and keeps the log readable. Teams that rebase confidently move faster and debug less.

To see this process in action without risking your repo, try it on hoop.dev. Spin up a safe development environment, run through a real Git rebase screen, and watch it work in minutes.