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.

By the end of this post, you will have Microsoft's GVFS up and running on your PC, and be able to use it with gmaster, your favorite (I-hope-so) Git client.

Size comparison between a full clone and a GVFS clone

The cool thing about GVFS, in case you didn't know, is that you can now have large Git repositories on your PC, -even the ones too big for your hard drive-, while the operations on it are still super-fast, regardless of its size.

This is because you won't really have the entire repository on your PC. GVFS, short for Git Virtual File System, will silently download on demand the necessary files to your PC, just when you or any other program on your PC require them. You can read more about how GVFS works here (you'll see our logo at the bottom!); this post is just a guide to get you started with GVFS and gmaster.

By the time I'm writing this, GVFS requires a computer with Windows 10 1703 (Creators Update, released on April 2017) or later. Because it also requires a service that supports the GVFS protocol, for now you are restricted to using Visual Studio Team Services if you want to try GVFS, although other big players in the field, such as GitHub and BitBucket are working to bring GVFS support to their platforms, and GitHub is working with Microsoft to bring GVFS support to GNU/Linux and macOS.

Are you ready? Ok, let's go!