Interactive Rebase in SourceTree

some developers regard git’s rebase feature as mysterious – even dangerous! while inexpert rebasing can indeed cause annoying problems for your teammates, rebase done right is perfectly safe. it’s also a handy way to clean things up before pushing to origin or merging back into master.

but ‘mysterious”? no need for that.

in this post, i’ll provide a brief overview of rebase, and it’s cousin, interactive rebase. then we’ll dive into interactive rebase using sourcetree (a free ui tool for working with git commands ) and the operations you can perform during it: squash, edit, delete, reword, and reorder.

don’t have sourcetree yet? take a tour and download it free at sourcetreeapp.com

rebase vs. interactive rebase

you may have heard terms like “rewriting history” or “replaying your commits” in the context of rebasing, which can be confusing if you’re new to git . essentially, rebase is a way of changing your commit history.

why call the operation “rebase”, though? because rebase lets you choose a new base commit to serve as the starting point for your feature branch. you can also rebase against a commit on your current branch, then reapply (or “replay”) subsequent commits on top of that. like so:

basic rebase is a good idea when you’re about to merge into master, and master has progressed since you branched off of it. by reapplying all your branch commits onto a different base commit, you flush out merge conflicts before you go to perform the actual merge. and if you kick off a test run against your rebased branch (which you would totally do, because you’re conscientious – right?), you’re can discover integration issues before pushing your changes to origin.

interactive rebase is a variation that lets you tidy up your commit history before merging or pushing to origin. changing the commit history lets you apply 20/20 hindsight to describing the steps you took to get to this change. git has a special file called git-rebase-todo which is simply a text file containing a list of the commits you’re working with. interactive rebase offers a chance to edit this file and gives you some control over exactly what happens when you replay those commits.

warning : even though it looks like you’re just shifting your commits to a different point in your repo’s history, under the covers, git actually creates new commits – each with a new sha. so don’t rebase commits you’ve already pushed to origin unless you coordinate closely with your teammates. they’ll need to bring their local copy of the repo up to date afterward.

interactive rebase using sourcetree

if you’re doing an interactive rebase from the command line, git will open an editor where you an issue the commands that result in edits to git-rebase-todo – which is sort of like a runbook git will use when executing the rebase. similarly, sourcetree taps into git-rebase-todo and edits it. the difference is the user experience: you get to interact with the rebase through a point-n-click ui instead of having to memorize commands and their syntax.

learn more about the internal mechanisms of interactive rebase on our free git tutorials site .

there are two ways to start an interactive rebase in sourcetree. the first is to right-click (or context-click) on a commit and choose rebase children of <sha> interactively… the second is to pull down the repository menu and select interactive rebase.

from there, you’ll have the chance to rewrite your repository’s history with the help of a few operations. let’s walk through them one by one.

squashing

squashing is a nice way to tidy up after a series of “panic commits” – when you write a line of code, then are overcome by fear of a sudden widespread power shortage resulting in the loss of your work. panic commits tend to be small and, taken in isolation, rather trivial. squashing lets you combine tiny-yet-related commits into a single, meaningful commit.

to use the squashing feature in sourcetree, just drag and drop rows on top of one another. or, you can use the squash with previous option by right-clicking or using the button at the bottom of the dialog.

editing commit contents

some commits just aren’t quite right. but the git commit –amend command lets you do things like change the commit message or add staged changes to a previous commit.

to use this feature, check the “amend commit?” checkbox on the commit you’d like to edit. when rebasing continues, it will drop back out to sourcetree allowing you to do whatever the heck you want before continuing on.

rewording commit messages

when you’re in the middle of solving a problem, you don’t know how the whole story will read. but now that you’ve solved it, you do. rewording commit messages lets you tell the story in a way your colleagues (and your future self) will be able to make sense of.

double-click on the “description” column in the interactive rebase screen. a window will pop into view where you can tweak or completely replace the commit message.

rewording commit messages is also useful after you’ve added staged changes to an existing commit. in fact, you really ought to update the commit message in such cases so it’s clear to everyone what the commit now contains.

deleting

this is one to use with caution. but if you absolutely must delete a commit (and you’re absolutely certain doing so won’t wreak havoc on your repo), you can do it as part of an interactive rebase in sourcetree.

as with squashing and rewording, double-click on the description of the commit you want to nuke, and select “delete commit” . and *poof* – it’s gone.

reordering

once upon a time, i got into trouble because the commit history of a repository clearly showed i was working on feature y before feature x, contrary to the project plan. i’ve also seen commit histories where commits for feature x were scattered around and interleaved with commits for feature y, making it hard to get a sense where feature x is at in its development.

whether to save yourself from reprimand, or to group related commits together for ease-of-grokking, reordering commits is easy. just drag and drop them in sourcetree’s “reorder and amend” window.

avoiding confusion during interactive rebase

“mine” vs. “theirs”

let’s say you’ve deleted a commit, and git is now replaying subsequent commits. let’s also say one of those subsequent commits affects a file that was changed as part of the commit you deleted. git won’t know which version of that file to replay the other commits on top of, so it has to ask you: mine or theirs ?

in this case, mine refers to the changeset just prior to the commit you deleted, and theirs refers to the changeset just after the commit you deleted. if you choose mine , you’ll lose all the changes made to that file after the deleted commit. proceed thoughtfully in this situation, and don’t rush through it. but even if you do make a mistake here, you can still reset your repository as long as you don’t push the changes .

rebasing upstream commits

i said it above, but it bears repeating: never rebase commits that have already been pushed. this can lead to dangerous and confusing situations.

if you rebase pushed commits, sourcetree will tell you that you’ve got changes to pull down after you’ve finished the rebase. this is really confusing if you know you’ve pulled all the changes already. here again, you can save your team from experiencing this confusion by resetting your repo as long as you don’t push these changes.

rebase with confidence

interactive rebase can be really useful, especially if you tend to commit locally all day long and push your changes on your way out the door. up to the point of pushing, you can condense, delete, or just edit the message on your commits to make the history easier for everyone to understand.

give it a try next time you’re iterating quickly on a feature or fix. and tweet us up @sourcetree if you run into issues or have any feedback for us. happy coding!

for more on rebasing, workflows, and other git commands, check our free tutorials site. you’ll find advanced tips for experts, as well as getting-started help for newbies.