Clean Your Feature Branch with Sourcetree’s Interactive Rebase

Problem: A messy commit history before a merge

When you work on a feature branch, it’s common to end up with several small, experimental, or typo‑laden commits. A clean history makes code reviews easier, keeps the project history readable, and reduces merge conflicts later. The traditional way to tidy commits is git rebase -i, but the command‑line interface can feel intimidating for developers who prefer a visual workflow.

What you want is a tool that lets you rewrite history step‑by‑step, with a preview of the new commit order, and that integrates conflict resolution directly into the UI. Sourcetree’s Interactive Rebase satisfies that need.

Thesis: Sourcetree’s Interactive Rebase is a safe, visual alternative to command‑line rebasing.

With Interactive Rebase you can:

• Re‑order, squash, edit, or drop commits without typing a command.
• See a live preview of the rewritten history in the Rebase dialog.
• Resolve conflicts in your editor and then continue the rebase from the same window.

Below is a practical walk‑through that shows how to use this feature on a typical feature branch.

1. What Interactive Rebase Does

Interactive Rebase rewrites the commit history of the current branch. It takes a list of commits and lets you decide how each one should appear in the new history:

• pick – keep the commit as‑is.
• squash – merge the commit into the previous one.
• edit – stop to amend the commit message or content.
• drop – remove the commit entirely.

Because the operation rewrites history, it should only be used on branches that have not yet been shared with others, or after you coordinate with teammates.

2. Open the Interactive Rebase Dialog in Sourcetree

1. Open the repository in Sourcetree and check out the feature branch you want to clean up.
2. Right‑click the branch name in the Branches pane and choose Rebase children of <branch> onto <branch>.
   • Alternatively, click the Rebase button in the toolbar and select Interactive Rebase from the drop‑down.
3. The Interactive Rebase dialog appears. It lists the commits from the oldest to the newest. The first commit in the list is the one that will become the new base of the branch.
4. Select the target branch (usually main or develop) in the Onto field. This tells Sourcetree where to re‑apply the commits.
5. Verify that the commit range is correct. The dialog shows a preview of the new history on the right side.

3. Manipulate Commits: Pick, Squash, Edit, Drop

Use the toolbar icons above the commit list or the keyboard shortcuts to change the action for each commit:

• Pick (✓ icon) – keep the commit. Default for all commits.
• Squash (⟲ icon) – merge into the previous commit. The commit message of the previous commit will be edited to include the squashed commit’s message.
• Edit (✏️ icon) – pause the rebase so you can modify the commit. After editing, click Continue Rebase to resume.
• Drop (– icon) – remove the commit entirely.

Tip: Drag and drop commits to reorder them. The preview updates automatically.

4. Worked Example: Cleaning a Five‑Commit Feature Branch

Assume the following commit history on branch feature/cleanup:

commit 5 – "Add README"
commit 4 – "Fix typo in docs"
commit 3 – "Add helper function"
commit 2 – "Initial feature implementation"
commit 1 – "Create feature branch"

Goal:

1. Squash commits 4 and 5 into commit 3.
2. Edit the message of the new squashed commit to "Add docs and README".
3. Drop commit 2 because it’s a duplicate of commit 3.

1. Open the Interactive Rebase dialog on feature/cleanup and set Onto to main.
2. For commit 5, click the Squash icon. The preview shows commit 5’s changes merged into commit 4.
3. For commit 4, click the Squash icon again so that both 4 and 5 merge into commit 3.
4. For commit 3, click Edit. Sourcetree pauses the rebase and opens the commit message editor. Change the message to "Add docs and README" and save.
5. For commit 2, click Drop to remove it from the history.
6. Click the green Rebase button to start the operation. If any conflicts appear, resolve them in your editor, then click Continue Rebase in Sourcetree.
7. After the rebase completes, the history pane shows:

   commit 5 – "Add docs and README"
   commit 4 – "Create feature branch"
   

8. Push the updated branch to the remote with Push (force if necessary).

5. Trade‑Offs and Limitations

• History Rewriting – Interactive Rebase rewrites commit hashes. If the branch has already been pushed and other developers have pulled it, they’ll face divergent histories. Coordinate with your team and consider using git push --force-with-lease only after everyone is aware.
• Conflict Resolution – During a rebase, conflicts may arise. Sourcetree pauses and lets you resolve them, but you still need to know how to edit files and stage changes. If you’re new to conflict resolution, review the git status output in the console.
• Backup Recommendation – Before starting a rebase, create a backup branch: git branch backup-feature/cleanup. If something goes wrong, you can return to the original state.
• Performance on Large Histories – Interactive Rebase can be slow if the branch contains hundreds of commits. In such cases, consider using the command line or splitting the rebase into smaller chunks.

6. Actionable Take‑aways

• Use Interactive Rebase only on local or private branches that haven’t been shared widely.
• Always create a backup branch before rewriting history.
• After the rebase, review the new commit list in Sourcetree’s history pane to confirm the order and messages.
• Push the cleaned branch with Push and, if necessary, --force-with-lease to update the remote.
• Communicate with teammates before force‑pushing. Provide a brief summary of the changes you made to the history.

Interactive Rebase in Sourcetree turns a potentially error‑prone command‑line operation into a guided, visual process. By following the steps above, you can keep your commit history tidy, make code reviews smoother, and maintain a clean collaboration workflow.