GitKraken Interactive Rebase: Squashing Commits Visually

A feature branch that works but reads like a debugging diary — fix typo, actually fix test, wip, wip again — makes review and later maintenance harder. GitKraken offers a visual interactive rebase that lets you reorder, squash, and reword commits by dragging and right‑clicking on the commit graph. This can simplify cleanup, but it’s still Git under the hood: rebasing rewrites commit hashes, so the same safety rules apply.

What the visual rebase actually does

GitKraken’s commit graph is its central view. Right‑clicking a commit surfaces actions such as Squash, Reword, Drop, and Reorder. You can also drag one commit onto another to initiate a squash. These interactions generate a standard git rebase -i sequence; the GUI does not change Git’s behavior, it only maps familiar UI patterns to the same underlying commands.

Because the mechanism is identical to the CLI, two things follow: everything you learn here transfers to the command line, and Git’s rule about not rewriting shared history remains absolute. Any commit that has been pushed to a remote or pulled by a teammate must be coordinated before you rebase.

Why squash before merging?

Collapsing work‑in‑progress commits into a single, well‑described commit pays off in two concrete ways:

• Readable mainline history. Reviewers see one atomic change with a meaningful message instead of a step‑by‑step transcript.
• Functional tooling. git bisect assumes each commit is a coherent, testable state. A history littered with wip commits makes bisection noisy. Likewise, git revert works cleanly on an atomic commit but becomes error‑prone when a logical change is spread across several partial commits.

Worked example: five commits to one

Assume a feature branch with this history (oldest first):

add rate limiter middleware
fix typo
actually fix test
wip
address review comment

With the branch checked out in GitKraken:

1. Squash the WIP commits. Drag fix typo, actually fix test, and wip onto add rate limiter middleware. When prompted, choose Squash. Repeat for address review comment if you want it included. The exact prompts and whether multiple commits can be squashed in one pass depend on the GitKraken version — test in a scratch repository first.

2. Reword the surviving commit. Right‑click the resulting commit and select Reword. Replace the message with something like Add rate limiting to public API endpoints.

3. Push with lease. Because the rebase rewrote hashes, a normal push will be rejected. In GitKraken’s push dialog, look for an option labeled Force push (with lease) or similar. This option runs git push --force-with-lease, which refuses to overwrite the remote if new commits have appeared since your last fetch. The CLI equivalent for reference:

   git push --force-with-lease origin my-feature-branch

   Run this from the repository root; it requires write access to the remote. The pull request will update in place with the cleaned history. Risk: if a teammate based work on the old commits, their branch now diverges — coordinate before rebasing anything that has been shared.

The rule that doesn’t bend

Interactive rebase is safe for commits that exist only locally or on a branch you alone use. It is not safe for commits others have pulled or built upon. A common team policy:

• Rebase freely on your own feature branches.
• Never rebase main or shared integration branches.
• Announce before force‑pushing a branch others might have checked out.

Limitations and considerations

GitKraken is a commercial product. Feature availability and which repository types (e.g., private repos) are included in the free tier have changed in the past. Check the vendor’s current pricing page before standardizing a team on it — do not assume the interactive rebase you see in a demo is available in the tier you would use.

The GUI does not cover every Git operation. Advanced history surgery (e.g., git filter-branch style rewrites), complex reflog recovery, or scripted multi‑branch rebases still require the CLI. Also, the visual convenience can obscure what’s happening: if you don’t understand that squash rewrites hashes, the force‑push prompt may surprise you at the worst moment.

A complementary feature worth knowing: GitKraken’s merge conflict editor presents ours/theirs panes with an editable output view, which can be easier than hand‑editing conflict markers — especially when a rebase hits a conflict mid‑squash.

Verify in a test repository

Before applying this workflow to a real project, create a scratch repository, make a few throwaway commits, and walk through the drag‑and‑drop squash and reword steps. Confirm the context menu offers the actions you expect (squash, reword, drop) and that the push dialog includes a force‑with‑lease style option. UI elements can vary between releases, and ten minutes in a scratch repo is cheaper than a mangled shared branch.

Key takeaway: GitKraken’s interactive rebase makes squashing and reorganizing commits more visual and immediate, but it’s still Git under the hood. Use it to your advantage, but respect the rules around rewriting shared history.