GitKraken Interactive Rebase: Visual History Rewriting Without Memorizing Flags

The problem: rewriting history without a cheat sheet

Every Git user eventually needs to clean up a feature branch — squash a stack of “wip” commits, reorder a few patches, or rewrite a message. On the command line that means git rebase -i and a mental map of the pick, squash, fixup, reword, edit, drop, and exec actions. Miss a flag or mistype a commit hash and you’re digging through git reflog to recover.

GitKraken replaces that mental map with a drag‑and‑drop commit graph. The thesis of this post: the visual rebase panel makes routine history editing safe and discoverable, but it still leaks when the repository grows large, when commits are signed, or when you need advanced merge‑preserving rebases.

How the interactive rebase panel works

• Graph‑driven entry point. Right‑click any commit in the topologically sorted DAG and choose Rebase onto… or drag a commit onto a new base branch. GitKraken opens a dedicated panel that mirrors the git rebase -i todo list.
• Action dropdown per commit. Each row shows pick, squash, fixup, reword, edit, drop, exec. Changes are staged in memory; nothing is written until you press Start Rebase, letting you preview the resulting graph.
• Three‑pane conflict resolver. When a rebase hits a conflict, the same merge tool used for regular merges appears (base, local, remote) with inline diff highlighting and a Resolve using… picker. Resolved files auto‑stage and the rebase continues with one click — no git rebase --continue required.
• Session‑wide undo. Ctrl/Cmd+Z rolls back the last graph manipulation, even a multi‑commit squash, without touching git reflog.
• Crash‑recovery state file. While a rebase is active GitKraken writes .gitkraken/rebase-state.json alongside .git/rebase-merge. The file disappears on successful completion, giving you a safety net for forced closes.

Worked example: squashing two “wip” commits into one

1. Open the repository in GitKraken ≥ 9.0.
2. Locate the two consecutive wip: adjust padding commits on your feature branch.
3. Right‑click the older of the two and select Rebase onto… → choose the same branch (or a target branch) as the new base.
4. In the rebase panel, change the action for the newer commit from pick to squash. The older commit stays pick.
5. Press Start Rebase. GitKraken shows a preview of the new single commit in the graph.
6. If a conflict appears (e.g., both commits touched the same line), the three‑pane resolver opens. Choose Resolve using local (or remote/base) and click Continue.
7. When the rebase finishes, the graph now shows one commit with the combined message. Press Ctrl/Cmd+Z to verify the undo restores the two original commits.
8. Optional: verify the recovery file existed during the operation:

   ls -la .gitkraken/rebase-state.json   # should appear while rebase runs
   ls -la .gitkraken/rebase-state.json   # should be gone after “Finish Rebase”
   

Trade‑offs and known leaks

Area	Behaviour	Impact
Large repositories (>10 k commits)	Graph virtualizes rendering, but the rebase panel still loads the full todo list on first open. GitKraken 9.x added a “Load more” paginator to mitigate lag.	First‑open latency of several seconds; scroll becomes smooth after pagination.
GPG/SSH signed commits	Signatures are retained only if the private key is in the agent. GitKraken prompts for the passphrase per commit unless gpg-agent caching (TTL) is configured.	Unattended CI‑style rebases stall on each signed commit.
Missing advanced flags	The UI does not expose --update-refs or --rebase-merges. Complex merge‑preserving rebases still require the CLI.	Power users must drop to terminal for those workflows.
Submodules	Submodule commits appear in the parent graph but cannot be rebased from the parent UI.	You must open the submodule as a separate repository to rewrite its history.
Exec action output	exec runs shell commands in the repo root but only surfaces a red toast with the exit code; stdout/stderr are not shown.	Debugging failed exec steps is harder than in a terminal.

Actionable next steps

If you haven’t tried the visual rebase yet, spin up a small test repository (even a handful of commits) and run through the squash example above. Verify that:

• The .gitkraken/rebase-state.json file appears during the rebase and disappears afterward.
• Ctrl/Cmd+Z restores the pre‑squash graph instantly.
• Conflict resolution uses the three‑pane tool and auto‑stages resolved files.

For larger codebases, enable gpg-agent caching (gpg-agent --daemon --default-cache-ttl 3600) before rebasing signed commits to avoid per‑commit prompts. When you hit a scenario that needs --rebase-merges or submodule history rewriting, fall back to the CLI — GitKraken’s UI is a complement, not a full replacement.

Give the drag‑and‑drop rebase a try on your next feature branch; you’ll likely find the mental overhead of git rebase -i disappears, while the safety net of undo and crash‑recovery stays intact.