Cleaner Git History With TortoiseGit Interactive Rebase Before Merge

A feature branch with five commits like "wip", "fix typo", "temp", and "actually works now" is a code review problem. Reviewers read intent from history, not just the final diff. TortoiseGit makes interactive rebase visual on Windows, so you can reshape local history before it becomes shared without memorizing rebase -i syntax.

The problem: messy local history becomes permanent history

Interactive rebase is Git’s way of rewriting a sequence of commits. It lets you pick, squash, edit, or drop commits in a range, then replay them onto a new base. Squash merges multiple commits into one with a combined message. Edit pauses the rebase to amend a commit. The key engineering rule is that rewriting is safe only for commits that have not been pushed to a shared remote. Once collaborators have fetched them, rewriting breaks their clones.

TortoiseGit is a Windows shell extension. It adds Git commands to Windows Explorer context menus, so operations start from a folder rather than a terminal. Under the hood it delegates to an installed Git for Windows, so Git version and credential helpers still apply.

How TortoiseGit surfaces interactive rebase

The visual entry point is the Show Log dialog. From a repository folder you can open Show Log, which displays the commit graph with branches. Selecting a contiguous range of commits on the current branch exposes rebase-related actions.

When you start a rebase on a selected range, TortoiseGit presents a commit list where each commit is assigned an action. The default is pick to keep the commit as-is. Changing an action to squash merges that commit into the previous one, edit pauses for changes, and skip removes it. The dialog is a visual substitute for the interactive rebase todo list you would edit in a text editor on the command line.

Because the UI shows the graph, you can see which commits are local-only versus those that already exist upstream. That visual cue helps enforce the shared-history rule before you confirm.

Worked example: squashing WIP commits into two reviewable commits

Consider a local feature branch with five commits created during development:

• add initial scaffold
• wip: try approach A
• fix approach A
• wip: try approach B
• finalize feature

A cleaner history for review would be two commits: one for the scaffold and one for the finished feature.

Conceptual steps in TortoiseGit:

1. Open the repository folder in Windows Explorer and open Show Log.
2. Select the range from the first WIP commit down to finalize feature on the current branch.
3. Start an interactive rebase on the selected range.
4. In the action list, set the first WIP commit to squash into the scaffold commit, and set the remaining WIP commits to squash into finalize feature, keeping the two meaningful messages.
5. Confirm the rebase. TortoiseGit replays the commits with the new actions.

To verify the result, open a terminal in the repository and run git log --oneline on the branch. You should see fewer commits with the intended messages. The working tree should remain unchanged if the rebase completes without conflicts.

Trade-off and limitation

Rewriting history is the trade-off. It improves readability but is destructive to shared history. If the branch has already been pushed, rebasing changes commit hashes. Collaborators who have fetched the old commits will see divergence on the next pull or push.

TortoiseGit is Windows-only. Teams with macOS or Linux developers cannot standardize on the same shell UI, which matters for documented workflows. Menu labels and dialog layouts also vary between TortoiseGit releases, so describe the workflow by concept rather than exact clicks.

Force-pushing after a rebase is not routine. If a push is required, it must be done with explicit force options and awareness of the lease concept in Git to avoid overwriting others’ work. Treat force-push as a deliberate, reviewed step.

Actionable close

Use interactive rebase in TortoiseGit only on local, unpushed work to compress WIP into meaningful commits before opening a pull request. Keep the Show Log graph open to confirm commits are local-only, perform the rebase, then verify with git log --oneline. If the branch is already shared, prefer merge or fixup commits instead of rewriting.