Rewriting Git History Safely with Sourcetree's Interactive Rebase

Why you might need to rewrite history

Developers often discover that a series of commits on a feature branch contain minor edits, duplicate changes, or stray debug prints. Manually rewriting those commits with git rebase -i works, but it requires terminal comfort and risks breaking a shared branch if you force‑push.

Sourcetree offers a visual alternative: an interactive rebase dialog that lets you reorder, squash, edit, or drop commits by dragging items in a list. The result is the same history you would get from a manual git rebase -i command, but without typing complex syntax.

How the UI maps to Git internals

When you open the dialog, Sourcetree shows a list of commits in topological order. Each row has an action column with dropdowns for pick, squash, fixup, edit, reword, and drop. Changing a dropdown or dragging a commit changes the underlying .git/rebase-merge/git-rebase-todo file, which Git reads when it runs git rebase -i under the hood.

The dialog also highlights the rebase target range and warns if a conflict will pause the sequence. At that point the built‑in merge tool opens side‑by‑side, letting you resolve the conflict exactly as you would during a normal merge.

Concrete example: cleaning a feature branch

1. Open your repository in Sourcetree and go to the Log/History view.
2. Right‑click the commit that starts the series you want to rewrite and choose Rebase children of <hash> interactively…. The dialog appears.
3. Assume the branch has three commits: A (add login page), B (fix typo), C (add unit test). You want A and B to become a single commit, and you need to edit the message of C.
4. Drag B above A so the order becomes B, A, C. Then change the action for B to squash and for A to pick. Finally, click the reword dropdown for C.
5. Check the Autostash box. This runs git stash before the rebase and git stash pop after, preserving any uncommitted work.
6. Press Start Rebase. Sourcetree invokes git rebase -i with the generated todo list. If a conflict occurs, the merge tool opens; resolve it and click Continue Rebase.
7. When the dialog closes, the three commits are now two: a squashed commit containing the login page and typo fix, and a new commit with the edited message for the unit test.

After the rebase finishes, the Push dialog shows a “Force push” warning. You must tick the explicit checkbox to push the rewritten history, which prevents accidental overwrites of teammates’ work.

Key limitations to keep in mind

• History rewrite is destructive. Force‑pushing a branch that others have based work on creates divergence and may require additional coordination.
• Large rebases (hundreds of commits) can feel sluggish; Sourcetree 4.2+ added virtualized list rendering to improve responsiveness, but very large histories may still lag.
• Submodule commits inside the rebased range are not automatically updated. After the rebase, run git submodule update --init --recursive or sync submodules manually.
• On macOS, the bundled merge‑tool helper may be blocked by Gatekeeper on first run; you must allow it in System Settings → Privacy & Security.
• The UI does not expose the --rebase-merges option introduced in Git 2.18, so merge commits are flattened unless you perform the rebase via the command line.

When to avoid interactive rebase

If your branch is heavily shared, or if you rely on merge commits to preserve a complex integration history, consider using a regular merge or rebasing only on a private fork. For feature branches that are still in early development and not yet merged, the visual rebase is usually safe and highly productive.

Actionable closing checklist

1. Verify Sourcetree’s Git version: Help → About (Windows) or Sourcetree → About (Mac). It should be Git 2.45+ on Windows; macOS uses the system Git, which should be similarly recent.
2. Open the rebase dialog via the Log/History view as described above.
3. Enable Autostash if you have uncommitted changes; otherwise stash manually before starting.
4. Perform the desired reordering, squashing, or editing using the UI controls.
5. If a conflict appears, resolve it with the built‑in merge tool, then click Continue Rebase.
6. After the rebase completes, check the Push dialog for the “Force push” warning and confirm the checkbox before pushing.
7. Run a quick verification: open .git/rebase-merge/git-rebase-todo while the dialog is open to ensure UI actions map to the correct todo instructions.

By following these steps, you can rewrite commit history cleanly without leaving the Sourcetree interface, while staying aware of the risks and limitations.