gmaster - The Git GUI client for Windows

My name is Ralf Koban and I've been using gmaster since its initial preview, about 1 year ago. For me, the greatest value provided by gmaster is the semantic diff and merge.

I mostly used C# with gmaster during this time. But, then I realized I was missing support for specific files in my development such as .resx resource files (famous in the .NET ecosystem) and NDepend configuration files.

So, I decided to add custom support for these XML based languages myself.

And here is the improvement: text-based diff when the NDepend rule changes and relocation makes it impossible to follow what really happened (see the XML in the following figure XML).

Versus gmaster with NDepend support where it is very easy to follow how some rules were changed, moved and even renamed (see the example case for the rule on the top left labelled "methods too complex").

And here goes the full story :-)

gmaster comes pre-built with support for C#, C, C++, VB.Net and Java. But, you are not limited to these five languages; there are ways to develop and install support for additional languages.

We originally developed the external parser support for SemanticMerge, (which is now a key piece in gmaster), so you can check this guide we wrote explaining how to add new languages.

Users have already contributed parsers for Delphi, F#, Go, and a few others.

In this blogpost, I'm going to cover how to install an external parser in gmaster to add semantic support for new languages. For this demonstration, I chose the F# parser.

A semantic diff between two revisions of a F# file

In our previous posts, we introduced gmaster and Git and how we started sharing code between machines using remotes. In this post, we will cover how to organize and how to have a better branching strategy that will allow you to deliver projects with more quality and confidence.

Gitflow is a well-known workflow used in Git and we improved it with all the visual features of gmaster. It's a perfect match :) Basically, Gitflow defines some branching rules and how code flows between those branches.

Gitflow uses two main branches: master and develop. The master branch relates to the most stable version of your product and the develop branch is where you integrate new features before bringing them to master (or before reviewing them in a quality assurance process). The develop branch is also known as the integration branch.

In the last post, we talked about the first steps for using Git with gmaster and covered the first steps with both. For example, how branching and source-control can aid how you control versions of your work. And, how you can go even further and go back in time if you want to. This is the kind of magic found in source-control systems :)

Git is a distributed source-control system and it can keep a copy of the entire repository in each device that you want or have permissions to. This way, it can help teams collaborating with the same source-code base. You can even use this feature if you just want to share your source-code between your personal and work computers or as a backup copy.

Here are some scenarios that we will explore with Git:


Everytime that we have more than one repository (or copies from this repo), the one we are currently working on is known as the local repository and the other ones are called remotes.

How often do you have to stop what you are doing to solve a conflict in a pull request? How long does it take before you get refocused on the task at hand? Wouldn't it be great if a bot was able to automatically solve most of those merges so you don't have to waste time in context switching?

Well, that's precisely what we are working on. We call it mergedroid and it is a way to apply our Semantic Merge technology to the server side to reduce manual intervention when merging pull requests. It is the same merge tech that comes with gmaster, but applied to solve GitHub pull requests.

We found that between 16 to 30% of conflictive pull requests can be fully automated by mergedroid, saving tons of precious time.

This is what it can do with the Git repo itself:

Almost 27% less manual merges required. Check the full report here.

Do you want to learn more about mergedroid? Go to

gmaster (short for Git Master) is a Git GUI designed to solve 3 key issues that users face: branching is hard to understand, merging is a nightmare and committing changes is tougher than it should.

To solve these 3 key problems, we introduced 3 solutions in gmaster:

  • Natural branch visualization – so understanding branching becomes trivial.
  • Built-in merge tools with semantic superpowers - to remove the pain out of merging.
  • One step commits: to simplify saving changes.

These were the goals we had when we decided to develop it. And these are the key differentiators when you compare gmaster to all the other Git GUIs around.

Git is a powerful way to share and control source-code. It can keep track of source-code, its changes and collaborate with other developer's safely. But, unfortunately, most of the client tools that can communicate with Git are all based on command line (aka shell or prompt).

Remembering all the Git commands and their parameters are difficult and very hard on your brain. A branch-based approach becomes pretty hard to see and you can miss the whole overview of dependencies and relation between branches.

This is why a graphical interface client for Git can transform and improve your development process. And gmaster can take this to the next level. In this post, we are going to cover the first steps with gmaster and you will be able to see how much detail you miss by not using gmaster.