Cleaning Up a Feature Branch with GitKraken Interactive Rebase

The problem: a branch full of WIP commits

You finished a feature, but the branch history tells the real story: "fix typo", "actually fix it this time", "address review comment", three commits that undo each other. Merging that as-is pollutes the main branch and makes git blame and future archaeology painful. Interactive rebase lets you rewrite that local history into a small set of logical commits before anyone else sees it. GitKraken exposes this through a drag-and-drop commit list instead of the command line's text-editor todo file, which makes reordering and squashing noticeably less error-prone.

The takeaway: rewrite only commits that exist solely on your machine, verify the final tree matches what you started with, and keep the reflog as your escape hatch.

Prerequisites and the one hard rule

Interactive rebase rewrites commit hashes. Every commit it touches gets a new SHA, even if its content is unchanged. That leads to the hard rule:

• Safe: commits that have never been pushed, or that exist only on a branch nobody else has pulled.
• Dangerous: commits already on a shared branch. Rewriting them forces you to force-push, and any teammate who based work on the old commits now has a diverged history to untangle.

Before you start:

1. Confirm in GitKraken's graph that the commits you plan to rewrite have no remote counterpart, or that your team has agreed to a force push. Look for the remote branch label sitting at or past your local commits.
2. Commit or stash any uncommitted work. A dirty working tree blocks the rebase.
3. Note the current tip commit's SHA (click the commit; the SHA is in the commit panel). This is your manual recovery point if you skip the reflog route.
4. Make sure the target branch (usually main or develop) is fetched and up to date, so you rebase onto current code rather than a stale base.

Menu labels and which features require a paid license vary across GitKraken versions, so treat the exact wording below as approximate and check your installed version.

Procedure: squash, reword, reorder, drop

1. Fetch and check out your feature branch. Double-click the branch in the left panel or on the graph.
2. Start the interactive rebase. In the commit graph, right-click the commit just below the oldest commit you want to rewrite — typically the commit where your branch diverged from the target branch. Choose the interactive rebase option from the context menu. GitKraken opens a view listing every commit from that point to your branch tip, oldest at the bottom.
3. Reorder by dragging. Drag commits up or down to change their order. Reordering is useful when a fix commit logically belongs before the change that depends on it. Be aware that reordering commits that touch the same lines often produces conflicts.
4. Squash WIP commits. Drag a commit onto its parent (or use the squash action in the list) to combine them. GitKraken prompts you to edit the resulting commit message — write the message you wish you'd written originally, describing the logical change, not the journey.
5. Reword. Use the reword action on any commit whose message is vague ("changes", "updates") but whose content is fine.
6. Drop. Remove commits that should never have existed — debug logging, an experiment you abandoned. Dropped commits are gone from the new history; recovery depends on the reflog, which expires.
7. Run it. Confirm to execute the rebase. GitKraken replays the commits in your new order onto the base commit.

If conflicts appear

Rebase applies commits one at a time, so a conflict pauses the sequence. GitKraken opens its merge conflict editor: you can pick the ours/theirs version of a hunk or edit the result inline, then mark the file resolved and continue the rebase. Two things to know:

• The same conflict can resurface for several successive commits, because each replayed commit re-applies its own diff. If you find yourself resolving identical conflicts repeatedly, that is a signal a plain merge would have been cheaper than a rebase.
• If things go sideways mid-rebase, use the abort option. Aborting returns the branch to its pre-rebase state cleanly — this is the safest recovery and the reason you should not panic-resolve conflicts you do not understand.

Verification: prove the rewrite changed nothing but history

A successful cleanup changes history, not content. Check all three of these:

1. Graph shape. The GitKraken graph should show your branch as a short, linear sequence of commits sitting directly on top of the current target branch tip, with no merge bubble and no leftover WIP commits.
2. Tree equality. The final files should be byte-identical to what you had before the rebase. In a terminal at the repository root, run git diff <old-sha> HEAD using the SHA you noted in the prerequisites. Expected result: no output at all. Any diff means squashing or reordering lost or altered a change — stop and recover rather than pushing. This requires no special permissions, just read access to the repo.
3. Build and tests. Run your project's normal build and test suite on the rebased branch. Tree equality plus passing tests is strong evidence the rewrite is safe.

Recovery via the reflog

If you discover the problem after the rebase completed, the old history still exists in the reflog (Git's record of where HEAD has pointed). GitKraken can display reflog entries in the commit graph when the option is enabled in preferences. Find the entry for your branch tip from before the rebase — it will have the SHA you noted earlier — right-click it, and reset the branch to that commit (a hard reset, since you want the working tree back too). Alternatively, in a terminal: git reset --hard <old-sha>. This discards the rebased history, so be sure the SHA is the pre-rebase tip before running it. Act promptly: reflog entries expire (by default after weeks), so this escape hatch is not permanent.

Pushing the rewritten branch

If the branch was never pushed, a normal push works. If it was pushed before and you have coordinated the rewrite with your team, you must force push — and you should prefer force-with-lease semantics where available. Force-with-lease refuses the push if someone else has updated the remote branch since your last fetch, which prevents you from silently destroying a teammate's new commits. A plain force push has no such guard.

A lower-risk workflow: after verifying locally, push the rebased branch to a scratch remote branch and open a draft pull request. Confirm the diff shown matches exactly the change you intended, and only then update the real branch. GitKraken's graph makes divergence visible before you push — if the remote label sits somewhere unexpected, stop and find out why.

Limitations

• Exact menu labels, shortcuts, and free-versus-paid feature availability differ across GitKraken versions and license tiers; confirm in your installation.
• Interactive rebase on a long branch with many conflicting commits is often more work than a squash merge at pull-request time. If your team squash-merges PRs anyway, cleaning up the branch locally may be unnecessary effort.
• Reflog-based recovery is time-limited and local-only; it cannot save you after a force push has been pulled by others.