Git interactive rebase in a GUI: squash, fixup, reword, reorder and drop commits

An interactive rebase GUI lets you rewrite the commits on your branch from a list instead of a text file: choose a starting commit, give every commit above it an action (pick, squash, fixup, reword, edit or drop), drag them into a new order, and let Git replay them. It runs the same operation as git rebase -i, so the result is identical to the command line. In GitTree you right-click the commit just below the ones you want to change, choose Interactive Rebase of the Commits Above…, set the actions and click Start Rebase. If the result is wrong, Undo puts the branch back.

This interactive rebase tutorial covers each action, three ways to squash commits, the matching commands, autosquash and the safety net. The screenshots show GitTree’s interactive rebase editor, a free Git client for macOS, Windows and Linux, but the Git behaviour is the same in any tool.

What Git interactive rebase does, and when to use it

A normal rebase moves a series of commits onto a new base. An interactive rebase also lets you edit that series on the way: Git shows the commits it is about to replay, you change the list, and Git rebuilds the branch to match. Every rewritten commit gets a new id, which is why interactive rebase belongs to the stage before you share your work. Typical reasons to reach for it:

• Squash a run of “wip”, “fix typo” and “address review” commits into one meaningful commit before you open a pull request.
• Reword a commit message that has a typo, a missing ticket number or a vague summary.
• Fold a forgotten change into the commit it belongs to, so every commit builds on its own.
• Reorder commits so that a refactor lands before the feature that depends on it.
• Drop a debugging commit or an experiment that should never reach the main branch.

Pick, squash, fixup, reword, edit and drop: the rebase actions explained

Every line in an interactive rebase plan is one commit plus one action. These are the ones you will use day to day (Git’s todo file has a few more for scripting, such as exec and break):

Order matters, and it is the opposite of `git log`. The plan lists the oldest commit at the top, in replay order, while git log and most commit graphs show the newest first. A squash or fixup always melds into the commit directly above it, the older one. If a squash ends up at the top with nothing to fold into, GitTree refuses to start until you move it below a commit you keep.

The command-line equivalent: git rebase -i

On the command line you name the commit just below the ones you want to change: count back from HEAD, or use the point where your branch left main.

# rewrite the last 5 commits
git rebase -i HEAD~5

# rewrite everything since the branch left main, without moving its base
git rebase -i $(git merge-base main HEAD)

Git opens your editor with a todo list. This one is the same plan as the screenshot further down: the second commit is squashed into the first, and the fourth gets a new message.

pick f2cd67d chore(deps): upgrade Next.js and React
squash 19a1104 ci: cache pnpm store and run tests in parallel
pick f52edc8 refactor(api): extract repository layer from handlers
reword 05dfac2 feat(api): rate limit public endpoints
pick bf2385e fix(web): focus trap in the invite dialog

Save and close the file and Git starts replaying. It asks for the squash message and the reworded message, and pauses on any edit step or conflict, where you carry on or give up:

git rebase --continue   # after amending or resolving a conflict
git rebase --abort      # stop and put the branch back where it was

A GUI changes how you write the plan, not what Git does with it. GitTree runs the same plan with the Git already installed on your computer (version 2.39 or newer), so the app and a terminal produce the same commits. For the wider trade-offs, read Git GUI vs command line.

How to squash commits in a Git GUI

The short answer to how to squash commits: put them next to each other, leave the first as pick, mark the rest as squash or fixup, and replay. GitTree gives you three ways to get there.

Squash a group of commits in the rebase editor

Open the editor from the commit below the group, set its first commit to pick and the others to squash, or to fixup if you do not want their messages. Drag stray commits into place if the group is not contiguous. GitTree previews each group that contains a squash as the commit it will become, with the combined message in a box you can edit.

Select commits in the graph and choose Squash Commits

For a quick squash, select two or more consecutive commits of the current branch in the graph, right-click and choose Squash Commits. GitTree runs the rebase for you, and Undo can put the separate commits back. The same menu rewrites single commits in one step: Edit Commit Message…, Drop Commit…, Move Commit Up and Move Commit Down. These shortcuts work on commits that are not on a remote yet; for pushed commits, use the editor, which asks you to confirm first.

Squash when you merge the pull request

If your team keeps one commit per pull request, you may not need to rewrite the branch at all: GitTree’s pull request view can merge with squash, and your local branch stays as it was.

Fixup commits and autosquash: fix an old commit without reordering by hand

While you work, commit each small correction as a fixup of the commit it belongs to; Git titles it fixup! <original title>. Later, one interactive rebase with autosquash moves every fixup directly under its target and marks it fixup, so all you do is check the list and start.

# record a correction for an earlier commit
git commit --fixup=05dfac2

# correct the commit and replace its message too
git commit --fixup=amend:05dfac2

# later: fold every fixup! and amend! commit into its target
git rebase -i --autosquash main

# turn autosquash on for every interactive rebase
git config --global rebase.autoSquash true

In GitTree, run those commands in the built-in terminal docked under the graph, or type fixup!, a space and the original title in the commit message box; Git matches fixups by title, so both create the same commit. With the Arrange fixup!, squash! and amend! commits option on, the editor opens already arranged, and what you see is exactly what Git runs.

An amend! commit becomes fixup -C in the plan (“Fixup, use its message” in GitTree): its changes are folded in and its message replaces the target’s. Per the git-commit documentation, neither kind changes who authored the original commit.

Is interactive rebase safe? Undo, the reflog and force-with-lease

A rebase does not delete the old commits straight away: they stay reachable from the reflog until Git’s garbage collection clears unreachable objects much later. The real risks are losing track of the old branch and overwriting a colleague’s work on the remote.

Undo a finished rebase

GitTree snapshots the branch before every rebase, so Undo in the toolbar puts it back in one click, including other branches the rebase moved with update-refs, as long as nothing has moved the branch since. How to undo a git reset, rebase or commit covers the rest of that safety net. On the command line:

# still in the middle of the rebase
git rebase --abort

# already finished: go back to the tip from before the rebase
git reflog show --date=relative
git reset --hard ORIG_HEAD

Git sets ORIG_HEAD to the old tip when a rebase starts, but a git reset run during the rebase (to split a commit, for example) moves it. Right after the rebase, @{1}, the previous position of the current branch, still points to the old tip, so git reset --hard @{1} works too. git reset --hard throws away uncommitted changes, so commit or stash them first.

Rewriting commits you already pushed

GitTree labels commits that are already on a remote with “On a remote” and asks you to confirm before rewriting them. Afterwards a normal push is refused, so you need a force push. Use the lease form, which only overwrites the remote branch if it still points where you last saw it:

git push --force-with-lease

# safer when something fetches in the background
git push --force-with-lease --force-if-includes

A background fetch can refresh your remote-tracking branch and weaken the lease, so the git-push documentation suggests adding --force-if-includes. In GitTree a force push always uses --force-with-lease, pinned to the remote tip shown when you confirm, and that tip is kept locally under refs/ogt/trash, so the commits it removes from the remote are not lost. Undo cannot reverse a force push, because it changed the remote.

When a step stops: edits and conflicts

An edit step, or a commit that no longer applies cleanly, pauses the rebase. GitTree shows the plan’s progress and a banner to continue or abort. Conflicts open in the three-way editor, covered in resolving merge conflicts in a GUI. During a rebase Git swaps the sides of a merge: “ours” is the branch you are rebasing onto and “theirs” is your own commit, so GitTree labels them “rebasing onto” and “your commit”.

Tips for a clean commit history before a pull request

• Make every commit build and pass its tests on its own, and keep unrelated changes apart: one commit for the refactor, one for the feature.
• Rebase onto the latest main before you open the pull request, so reviewers see only your changes.
• Working with stacked branches? Turn on update-refs so the branches built on yours move with the rewritten commits.
• If the range contains a merge commit, GitTree shows it but will not rewrite it; use git rebase -i --rebase-merges for that case.
• Check the result in the commit graph before you push, and let your own AI coding CLI draft messages, as in AI commit messages with Claude Code and Codex.

GitTree is free today, private repositories included, on macOS, Windows and Linux, in English and Arabic. It needs a free GitTree account and Git 2.39 or newer. Get it from the download page, or compare the best Git GUI clients first.