Sourcetree Interactive Rebase: Architecture Note on Requirements, Design Limits, and Operational Safeguards

Requirements

Teams need a visual way to reorder, squash, edit, or drop commits without memorising git rebase -i syntax. The feature must preserve Git’s data model, surface conflicts early, and avoid accidental history rewrites on shared branches.

Smallest Suitable Design

Sourcetree implements interactive rebase as a modal dialog that reads the current commit graph, presents each commit as a row with action dropdowns (pick, squash, edit, drop, reword), and writes a temporary .git/rebase-merge/git-rebase-todo file when the user confirms. The UI does not add new Git commands; it only orchestrates the existing git rebase --interactive pathway.

Trust and Data Boundaries

• Local repository – All rebase work happens on the user’s clone. No network traffic occurs until the user pushes.
• Remote branches – The dialog warns when the target branch is tracked by a remote (e.g., origin/main) because a force‑push will be required.
• User credentials – Only the signed‑in account’s push permission matters; Sourcetree never stores tokens for the rebase itself.

Operational Checks

1. Open the repository in Sourcetree → Git menu → confirm Rebase is enabled (requires Git ≥ 2.23).
2. Select the branch tip, right‑click → Rebase children of … interactively.
3. In the dialog, verify the commit count matches the intended range (e.g., last 3 commits).
4. Choose actions; for squash, set the first commit to pick and the rest to squash.
5. Click OK. Sourcetree runs git rebase -i HEAD~3 under the hood.
6. If conflicts appear, the UI opens a conflict resolver; resolve, stage, then press Continue Rebase.

Failure Modes

• Conflict abort – User cancels; repository returns to pre‑rebase state (no history rewrite).
• Force‑push rejection – Remote rejects non‑fast‑forward; user must coordinate with team before git push --force-with-lease.
• Detached HEAD – If the rebase target is a tag or remote‑only ref, Sourcetree leaves HEAD detached; user must create a branch manually.

Conditions That Would Change the Design

• Git introduces a native --update-refs flag that safely rewrites multiple branches; Sourcetree could then offer multi‑branch rebase.
• Policy enforcement (e.g., signed commits) requires server‑side hooks; the client would need to surface hook failures before push.
• Performance regression on very large histories (>100k commits) may push the UI to a background worker with progress reporting.

Concrete Example: Squashing the Last Three Commits

# In Sourcetree UI
1. Checkout feature/ui‑tweak
2. Right‑click the tip commit → Rebase children of feature/ui‑tweak interactively
3. Set actions: pick (oldest), squash, squash
4. Edit combined commit message → OK
5. Resolve any conflicts → Continue Rebase
6. Push → Force‑push with lease (requires write permission on origin)

Equivalent command line for verification (run in the repository root, requires write access to the local repo):

git rebase -i HEAD~3
# edit todo list, save & exit
# resolve conflicts if any
 git rebase --continue
 git push --force-with-lease origin feature/ui-tweak

Verification Steps

• After rebase, open the History view; the three commits should appear as one with the new message.
• Run git log --oneline -5 in a terminal to confirm the squashed commit hash differs from the original tip.
• Check remote with git ls-remote origin feature/ui-tweak – the remote tip must match the new hash after push.

Limitations

Interactive rebase rewrites commit hashes; any open pull requests referencing the old commits will show outdated diffs. The feature does not automate force‑push safety beyond the --force-with-lease option. Git LFS files are untouched by rebase, but large binary history still contributes to repository size.