Switching from TortoiseGit to SourceTree

SourceTree allows me to manage more repos with less clicks which is great for daily use.

We use git at VDS to track all of the changes we make to code. Git is a great technology. It is a distributed source control system that allows each person that is doing work on a project to have their own copy of the source code. You can then make changes as needed without affecting others until you are ready. It supports this functionality really well. Aside from its distributed nature it also has multiple workflows you can work with. In addition, the branching and merging features are particularly powerful. Because of those features git is flexible and has become our tool for managing source control. Git is a great choice for modern agile approaches to software development. You can learn more about git here.

Git Bash Image
Git Bash

Git got its start in the Linux world. The default interface for git is a text console called Bash. Using Bash is similar to the Windows Command application. You have to know what the commands are and what their options may be. Then you type them out in Bash, press Enter and they run. This is powerful and flexible. It can also be tedious and requires a significant amount of knowledge to use the technology well. In situations such as these I prefer to use a graphical user interface (GUI). In Windows there are multiple GUIs for git. When I started using git in 2010 the only one I found useful was TortoiseGit. Given my preference for GUIs as opposed to text based interfaces I chose to use TortoiseGit to manage the git repositories.

Tortoise Shell Menu
Context Menu with
TortoiseGit options
highlighted

TortoiseGit is a Windows Explorer shell extension. You install it like any Windows application. To access it you use Windows Explorer and right click on folders or files. In the context menu that shows when you right click on these objects you will find additional options that provide access to git features. These options are placed there for you by TortoiseGit. When you right click on a git repository you get a access to a sub menu with many options. Each of those options is a command you can perform on the git repository or access to the to git's settings. TortoiseGit provides over a dozen commands from these menu options. Some of them change according to the current context of the object you clicked on. It is a nice system. It is reliable and there quite a bit of depth to what you can do with TortoiseGit. On occassion, I have needed to use Bash. That has been rare. I would say it is less than once a month.

One day a friend of mine, Richie Rump, was telling me how much he liked using Atlassian's SourceTree for his repository management. I was busy and downloaded SourceTree, opened it, saw it was quite different than TortoiseGit and moved on. I continued to use TortoiseGit for some months. One day Richie was working at our office and he was using SourceTree. I got to see it in action and liked what I saw. I decided to give it a try. From that second look on I liked how it managed some things much more easily than doing them in TortoiseGit. I have since switched. There are three primary features of SourceTree that helped me enough to make the change.

A couple of things about the work we do. We build and manage custom software systems for our clients. As such, on any one day, I may work on anything from one project to five projects. Each of those projects resides in a separate git repo. We also have a library of classes we have built at VDS that we use in multiple projects. Those libraries live in their own repo. To boot, each of those repositories houses multiple branches of the source code that are in different stages of development.

With TortoiseGit being a Windows Shell extension you need to have a Windows Explorer window open to the folder that holds a git repo by which you manage it. For me that meant I would have 2-3 Windows Explorers open all of the time just to manage the git repos of our library and the project I am focused on at the moment. If a call came in from a different client I would end up opening another Windows Explorer to manage that repo. As you can imagine this becomes a nest of open windows that is difficult to manage.  SourceTree solves this problem for me by providing one application that allows easy access to multiple repositories by representing each of the repos as a separate tab within the application. That gives me convenient access when switching from one repo to the other. A time and mental saver.

The second feature in SourceTree that is convenient to our workflow is brach switching. In TortoiseGit you switch branches by going to the Windows Explorer folder for the repo, right clicking to get the context menu then opening the git sub menu and selecting the Switch/Checkout... menu option or the Create Branch menu option. Then a dialog would show that allows management of the branches for the current repo. In SourceTree once you select the tab for the repo you are working on the branches are listed on the left side of the screen as part of a tree view that includes your remotes and other relevant information for the repo. If the current branch is up to date you switch branches by double clicking the name of the branch you want to switch to. If your current branch is not up to date you must commit/resolve your changes prior to switching, that's git at work and not the tool. If you're repo is not up to date and try to switch you are warned to complete your work by committing priror to switching. You create a new branch in SourceTree by right clicking the branches tree node and selecting the Create Branch... option from the context menu. All of that is much easier to do in SourceTree than in TortoiseGit. It saves time, which is my most valuable commodity.

Similarly doing a merge in SourceTree is much easier that in TortoiseGit, for the same reasons as above. No need to have a repo folder open, no need to right click and go to a sub-menu, etc. Don't get me wrong, I like TortoiseGit, it is a good tool and it is solid. I simply find using SourceTree to be more efficient for my everyday git usage. SourceTree has a number of other nice features, I'm not going to list them here, visit their site for that. One example can be found in the pull button where you get a count of how many commits your local repository is behind in comparison to the designated remote repository.

Tortoise Shell Menu
SourceTree Main UI

There is one part of using SourceTree that has been a gotcha for me. Earlier I mentioned there are multiple workflows for using git. The one most people think about is the pull request workflow as is commonly used at GitHub.com. Another workflow is the merge workflow. At VDS we use the merge workflow for our daily use. We are considering a switch to the pull request workflow, more on that in a later blog post. In the mean time, we will continue to use the merge workflow. So what's the issue you ask?

When you make changes to your local repo copy, commit them and then pull from the remote repository, if there are changes to the same files in the remote repository you get no warning in SourceTree. What you see is confusing, especially if you are coming from TortoiseGit. In TortoiseGit you get the resolve confilcts dialog if you do a pull and there are conflicts among the files. You can then deal with each change individually.  In SourceTree you don't realize that the merge is incomplete unless you notice that the pull icon's number of commits you are behind did not change after your pull. To see what has conflicts you have to press the Commit button in SourceTree. At that point you get a list of the files with confilcts to resolve. Even then, the first time I went through this I missed the list of files and pressed Commit. That gave me a bunch of files with the lovely git HEAD <<<<<<<< markers. Be careful when doing a pull. The easiest way to be sure you avoid this problem when using the pull/merge workflow in SourceTree is to press Commit right after pulling and to check which files have conflicts. Then go through each file, if any, and resolve issues as needed. At that point it is safe to press the Push button to commit your merged changes to the remote repo.

That has been the main issue I have run into while using SourceTree. On occassion, I have reverted to using TortoiseGit for a resolution or for checking on the history of a single file in the repo. In general, for my everyday work, SourceTree makes me more efficient and for that reason it is now my goto git repo management tool.