gmaster - The Git GUI client for Windows

When a contributor submits a pull request to a repository, this is a gift to an open source maintainer. But it can also contain a big challenge if there are merge conflicts.

A merge conflict indicates that the contributor changed files that others have changed in the main branch. When you attempt to merge two branches where people changed the same, Git attempts to merge those changes cleanly.

However, it’s not always possible for Git to reconcile those changes, resulting in merge conflicts. In those cases, it’s up to the maintainer to manually and painstakingly merge the changes. Or, as is often the case, they’ll ask the contributor to do it and push to the branch again. This is a lot of time-consuming tedious work.

mergedroid is a small GitHub app that connects to your repo and tries to automatically resolve merge conflicts in pull requests that GitHub can't. This saves tons of manual work. And it seems mergedroid can do a pretty good job, as the results in the ASP.NET Core repo show:

Branching and over engineering

Branching is a powerful tool but it has to be used wisely. Even so, when a project extends throughout the years, the sheer number of branches and changes committed to it can be impossible to handle. Unless you have an equally powerful tool like Branch Explorer.

Creating branches is an easy task for a machine. A ton of branches will never put in jeopardy the performance of your version control system (unless, well, they hold huge binaries, but that's another story). Branches, though, have another dimension to them. They are called branches because they stem out of a tree, being the tree the metaphor of the main line of development. Mainline itself is just another branch, only it's arbitrarily chosen at the beginning of each project as the branch in which the rest of the branches will be merged-to always. It will contain the latest version of the project from which the products and services are built, tested and eventually shipped.

Did you know?

Git stores branches in the shape of objects that have a pointer of the snapshot of the content committed along with its metadata. This pointer also links with the all the commits that were the direct parents of the commit that originated the object. A branch is a file that contains the SHA checksum of the commit it points to. Branches itself are not complex.

Welcome to Branchestown: branch madness

PHP is used broadly across the web. Any given user of a popular programming language like PHP would expect the tooling supporting the language to be problem-solving, right?

Well, that's all the latest gmaster update is about. If you are a PHP developer, you can now benefit from diff and merge capabilities that understand PHP.

In essence, what this means for PHP users is that using gmaster as your Git client will render more automatic merges to your code base as well as help prevent conflicts during integration. How does this magic happen? Read on.

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.