Using Sourcetree Interactive Rebase to Clean Up a Feature Branch Before a Pull Request

When a feature branch accumulates many small, exploratory commits, the history can distract reviewers and make the pull request noisy. The practical decision is whether to tidy that history before opening the request, and whether to do it in the terminal or with a GUI that lets you preview the rewrite.

What Sourcetree’s interactive rebase gives you

Sourcetree exposes Git’s interactive rebase as a dialog that lists every descendant commit of a chosen ancestor. For each row you can pick, edit, squash with the previous commit, reword the message, or drop the commit, and you can drag rows to reorder them. This covers the most common history‑cleanup tasks without having to remember the git rebase -i syntax.

Because rebasing rewrites commit hashes, Sourcetree blocks the operation on commits that appear to have already been pushed unless you explicitly enable force pushing. The force‑push option is off by default in Tools → Preferences on Windows and in Sourcetree → Settings on macOS, acting as a safety guardrail.

Worked example: squashing temporary fixes on a local branch

Assume you have a feature branch called feature/login that diverged from main. The branch contains three commits after the branch point:

1. Add login form
2. wip validation
3. Fix typo in label

The second commit is a temporary fix‑up that you would like to fold into the first commit.

1. In the Sourcetree repository view, locate the commit where feature/login branched from main. Right‑click it and choose Rebase children of <sha> interactively….
2. The interactive rebase dialog opens, showing the three commits in order. For the middle row change the action selector from Pick to Squash with previous.
3. Optionally edit the commit message for the combined commit to something like Add login form with validation.
4. Click OK to start the rebase. If no merge conflicts arise, Sourcetree updates the history graph to show two commits instead of three, each with a new hash.

To verify the result without relying on the GUI, open a terminal in the repository root (read‑only permission is sufficient) and run:

git log --oneline main..feature/login

Before the rebase you should see three lines; after the rebase you should see two lines, with the squashed commit message you specified. This check is non‑destructive and works regardless of whether Sourcetree is running.

If a conflict occurs during the rebase, Sourcetree highlights the conflicted files in its working‑copy view. Resolve them with your configured merge tool, then choose Repository → Continue Rebase or Abort Rebase from the menu. If the GUI hangs or exits unexpectedly, the underlying .git directory may be mid‑rebase; inspect it with git status in the terminal to confirm the state.

Trade‑offs and safety limits

Interactive rebase rewrites history, so you should only squash or reorder commits that exist solely in your local repository or on a branch you have explicitly agreed to force‑push with your team. Applying it to commits that teammates have already pulled will create divergent histories and require manual reconciliation.

Sourcetree’s visual preview reduces the chance of mistyping a git rebase -i instruction, but it does not change Git’s semantics. After a rebase that alters pushed history, a normal push will be rejected; you must enable the Enable force push option and then force‑push the branch. That extra step is intentional friction to prevent accidental history rewrites.

Menu labels, dialog layout, and the exact set of actions can differ between the Windows and macOS builds and across Sourcetree versions. Verify the dialog in your own installation before relying on it for a critical cleanup.

Actionable closing

Before opening a pull request, run the interactive rebase on your feature branch, squash or reword commits as needed, verify the result with git log --oneline, enable force push only if you intend to overwrite the remote branch, and then force‑push. Finally, confirm locally that the branch points from the expected base, the commit messages are clear, and no unintended changes were dropped. If anything looks wrong, abort the rebase while it is still in progress or reset the branch to the pre‑rebase state from the reflog.