SourceTree Blog

There are two major things I really gain out of rebasing frequently.

Firstly and most importantly, Thanks to rebase I'm constantly working against the most recent mainline, merge pains are reduced by frequently dealing with smaller rebase merges instead of trying to do one massive merge at the end when I'm finished with a longer life task that might last a week or two. The more often you merge the less painful it is.

Secondly there's the cleaning part of history involving squashing. I believe the issue with your viewing the merge history of the main line will miss out on changes that were able to be introduced fastforward without a merge. And frankly no one else on the team cares that I committed 6 times in the process of one task, they want to see all the code relevant to that task, and ideally it's all in one change set.

There's a pretty reasonable summary over here http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/

For certain teams rebase just makes a lot of sense.

I'm Tim, a dev at Atlassian. I just thought I'd chime in to let you know we are absolutely taking up the reins on SourceTree again! In fact, we're in the process of growing out our team. You can read a little more about it on the ST blog from earlier this year: http://blog.sourcetreeapp.com/2015/02/25/were-just-getting-started-with-sourcetree. We are aware of the performance issues affecting Windows users with certain repository shapes and have our backlog prioritized accordingly.

I haven't had much of a chance to play with GitHub Desktop yet, but it can only be a good thing for the users of all Git clients - nothing like a bit of healthy competition :) However, SourceTree's focus will remain on providing the best possible experience for professional teams using Git (and Mercurial).