Merge conflicts, handled inline
Conflicts are the most stressful moment in any rebase. Interactive Git Log turns them into a checklist: see every conflicted file, resolve, mark done, continue.
Conflicts appear where you already work
When a rebase hits a merge conflict, IGL doesn't throw you into an unfamiliar mode. It adds a list of unresolved conflicts to your uncommitted changes — the same panel where you stage and commit every day. Each conflicted file is right there, one click from opening.
Compare that to the CLI experience: a wall of red text, a paused rebase, and git status as your only map. The conflict itself is the same; what changes is whether the tooling helps you keep your bearings.
Resolve, mark, continue
The flow is a checklist. Open a conflicted file and fix it in VS Code's editor — accept one side, merge by hand, whatever the change needs. Then click the plus button next to the file in IGL to mark it resolved. When every file is marked, you're free to continue the rebase.
The visible list matters more than it sounds: with several conflicted files, the CLI gives you no progress indicator at all. IGL shows exactly what's left.
Stacked commits, multiple rounds
Rebasing replays commits one by one, so a stack of commits is checked for conflicts one-by-one too — it's entirely possible to resolve conflicts several times in a single rebase. This is normal, not a sign something went wrong. IGL surfaces each round in the same checklist format, so a five-commit stack edit that conflicts twice is just the same flow, twice.
Rebase conflicts vs merge conflicts
They're the same conflict markers, with one practical difference. A merge resolves all conflicts at once in a single merge commit. A rebase spreads them across the replayed commits — more rounds, but each one smaller and scoped to a single change, which usually makes them easier to reason about. Whichever you prefer, conflicts get dramatically less scary when the tooling tracks the state for you.
Frequently asked questions
How do I abort a rebase if it goes wrong?
git rebase --abort returns your branch to exactly where it was before the rebase started. Because IGL shows the commands and arguments it runs, you can always drop to the terminal mid-operation — the two stay in sync.
Why do I hit conflicts multiple times in one rebase?
A rebase replays your commits one at a time, and each commit can conflict independently. Rebasing a stack of five commits can mean resolving conflicts up to five times. IGL surfaces each round as it happens, so you always know which commit you're resolving for.
Does IGL include its own diff editor for conflicts?
You resolve the conflicted text in VS Code's own editor — the one you already know. IGL's job is the bookkeeping around it: listing what's unresolved, marking files done, and continuing the rebase when everything is clear.