Choosing a Git Client

Version control (VC) is very important for any type of IT shop, big and small, as well as for application code and database code. Most of my career I’ve used Microsoft’s Team Foundation Server (TFS) for my VC system. I have recently changed organizations and found VC to not exist in my new environment. This is a huge problem and, thankfully, management was excited to approve the project to stand up a system. I’ve chosen to go with Git for a number of reasons that I will not be getting into for this post.

With Git selected, I now have the task of choosing a Git client for Windows which I will then have to train my co-workers on. I have, and continue to use, via their GitHub for Windows (GHfW) client for personal projects. I like the client but I wanted to select the right client rather than the one that I’m used to. Which brings me to the goals / requirements that I’ve created for this selection process.

Goals / requirements

  • Graphical interface.
  • Freeware.
  • Single application for all Git interactions.
  • Must be as simple and intuitive as possible.
    • I want to be able to document the process completely but without writing a book that no one will read.
  • Shows version history.
  • Shows differences.
  • Detects changes in files.
    • I want the app to serve as a reminder to the user that they have not yet committed their changes.
  • Track commit authors.

Some of those requirements seem to be basic functionality which will be available in all clients. I made this list, however, to not only check to see if the app can perform the duty but also to compare how intuitively the interface handles those duties.


Using my personal experience with Git, a Google search, and a quick Twitter pole, I selected the below listed clients as the best potential candidates for analysis.


I chose TortoiseGit.


When installing Git, I installed Git GUI and Git Bash. After going through this client analysis I’ve grown to enjoy using Git Bash. Git Bash, however, is neither graphical nor intuitive. Which brings us to Git GUI.


The start-up screen is very simple and easy to use. You can see from the image above that UNC path repositories are possible. This became an important feature for me as I began defining the way we would handle various repositories within our organization. While its simplicity is a positive, I also found a negative here. Below is the window that you are brought to after opening a repository. If you typically use a single repository (repo) for your projects, you would likely do everything in this one location. We intend to have several repos and I felt that the need to exit the application and come back in through the start-up screen was not intuitive and mildly annoying.


Git GUI is very light weight using less than 7 MB of memory and loading in less than a second on an under powered laptop. It will detect changes in your files, once the repo is opened, and the commit process is intuitive.

Overall Git GUI stuck me as acceptable. Not much about it made me feel excited to select it but it meets all of the requirements and only has the downside of how you open and close repos.

GitHub for Windows

I have used GitHub for Windows a lot. I use it for personal projects and, naturally, for interaction with GitHub. It is a bit heavy, however. Using more than 100 MB of memory and taking more than 7 seconds to open on my test machine, I typically leave it open or practice patience.


The most notable pro for using GitHub for Windows is the interface. I find it the most intuitive of the three clients being compared. The visualization of differences and version history is great. The audience that I’m selecting this client for will only be using the most basic of Git commands, which makes this client appropriate.

I would like to note that it would not be good for anyone acting as a source control administrator. Likely I would select Git Bash or a different client for power users.

Sadly, this app ruled itself out for us by not supporting UNC paths. Also, I found that performing pulls from a git remote was not intuitive at all.


I ended up choosing TortoiseGit for our users. The primary reason for my choice was the fact that TortoiseGit is a Windows Explorer extension. As I mentioned above, I loved GitHub for Windows’ interface but it didn’t support UNC path repos. With GitHub out of the running, I find TortoiseGit much more intuitive than Git GUI because it utilizes folder structures that everyone using Windows already understands.


The menu, above, is customizable and extremely powerful. Viewing version history and differences is very similar to Git GUI. Unfortunately, you have to double click on each file that changed to see the differences, though. No preview pane was available.



I also liked the way TortoiseGit predicted the next logical step. For example, if you commit to master, on the window indicating completion, you can push a button to perform a push. It seemed that in most of the normal tasks you could flow from one window to the next easily, performing all of the commands that are necessary in your work flow.






2 responses to “Choosing a Git Client”

  1. Lucas Avatar

    There are a few others out there that I have used. Two of the top two candidates were GitExtensions, and SourceTree. SourceTree is the one that I’m using right now, it has a wonderful UI and amazing GitFlow Integration, it does not however offer a Windows Explorer like TortoiseGit offers.

  2. […] For a Change (of Environmental Variables) — Steven Murawski SQL Server Page Life Expectancy (PLE) Choosing a Git Client Identifying Transaction Log Backup Gaps The SQL Server Job Management You Wish You Had […]

Leave a Reply

%d bloggers like this: