#StandWithUkraine

SourceTree — layer of comfort for version control

While I had basic idea about version control for code before that, I had started using it seriously for work projects several years ago.

At the time Subversion started to get pushed out by newer distributed systems. We went with Mercurial over Git back then for friendlier behavior and safer defaults.

In the long run rising popularity of GitHub had crippled Mercurial’s chances for being common enough choice. I had gradually moved on to Git. Most of that I credit not even to GitHub, but convenience and power of SourceTree version control client.

What it does

SourceTree is graphical interface for Git and Mercurial version control. It puts what they do into more familiar form of desktop application. No scary command line in other words. :)

SourceTree interface

SourceTree interface.

You add your local repositories to SourceTree — by drag and drop, selecting from file system, or even getting list from remote hosted service (Bitbucket / GitHub) and cloning. Inside the app repositories can be organized with folders, independently of their location in file system.

Repositories get opened in tabbed interface. For each you can switch between current status, log of commits, and search mode.

Strong features

The one thing about SourceTree that made big improvement to my workflow is how well it supports interactive staging. No more thinking in terms of committing changes by whole file. It makes it very convenient to pick them precisely, down to individual lines.

This relieves my mind from need to code in a way “friendly” to version control. I just write at my own pace and organization, yet still can express those results in logical and clean sequence of commits.

SourceTree offers similar amount of polish in pretty much everything it does. It really takes the menacing alpha–geek mood out of version control workflows.

Want to make a pull request on GitHub? SourceTree gives you a single hotkey to magically push current branch to selected repo, open pull request to upstream, and drop you into browser with all details ready to only write description for it.

More things done, less time spent figuring out arcane command line arguments all around.

Downsides

SourceTree is a little too eager to mess with configuration. After few early incidents I went through settings and disabled everything related there, in favor of Git installed and configured in system by myself. Yet, I catch quirks to this day, usually related to global ignore settings.

While running SourceTree constantly polls repositories in background for updates. It is convenient, but with large number of repositories also can generate fair amount of background activity. Sometimes I get errors from it on shutdown, when those processes don’t close properly.

Overall

I know for some command line will forever be the right way to use version control. For myself SourceTree workflow is vastly preferable. It enables me to produce clean commit history, in less time and less direct interaction with Git. :)

Site sourcetreeapp.com

Related Posts

5 Comments

  • Ulrich #

    I got started with GitHub for Windows and it was great to get started understanding git. As it does not all of the commands I started to learn the commands and now love using the command line with the gui.
  • Andrey “Rarst” Savchenko #

    I am not sure what the current state of GitHub's own client is, but in early days it was completely horrible. :) I tried and run away screaming.
  • Paul #

    I used Sourcetree for a while, but then I switched to Tower, I like using a GUI for exactly the same reasons as you, makes it easier to organize commits. I can't remember exactly why I moved away from Sourcetree, might give it another try.
  • Andrey “Rarst” Savchenko #

    Tower is Mac only, right? So far I hadn't seen any other clients on Win that would tempt me to switch away from SourceTree.
  • slaFFik #

    I used Smartgit, but moved to SourceTree because of its "Stage lines/hunk" functionality - this feature is absolutely awesome. Plus managing different remotes for the same repo is easier there, comparing to Smartgit at that time.