Gitflow with gmaster

Thursday, March 15, 2018 10 Comments

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.

Tip: It is a good idea to protect those remote branches against the direct pushing of code. That way, you can only bring changes to them using merges/pull-requests. GitHub allows you to protect your branches in repo Settings > Branches > Protected branches.

Starting a new project

To try this workflow out, you can start a new repo in gmaster that is already connected to GitHub. You can add your initial file too and commit it. Then, create a new branch from master called develop. (In Branch Explorer, you right-click on master and select Create branch from this commit. We covered this in a previous post also). Finally, push those changes and branches to your remote (Github), by clicking Push. (Or, right-click each branch and select Push this branch).

You should have a Branch Explorer that looks like this:

Initial Branch Explorer

And in your GitHub branching view, something like this:

GitHub branches

Feature branches

You should create a new branch for every new feature that you are going to create in your project. So, this new branch will house every change or code of this feature. In Gitflow, this kind of branch is called Feature Branches.

Feature Branches should be created from a develop branch. This will allow it to already have new features that will be part of the next stable release. Another good practice to follow is to prefix its name with feature/.

To practice this, you can create a new branch from develop naming it: feature/adding-contribute-information. Later, add a new file, add some information to it and commit those changes. The Branch Explorer will look like this:

gmaster - Feature branch

You can push these commits too. So, in GitHub you are going to have the same structure:

GitHub - Feature branch

Integrating changes back to develop and releasing a version

Bringing these changes back to develop is easy; it's just a matter of merging back those changes. But, if you protected the develop and master branches in GitHub, you should open a new pull-request inside the GitHub screen. You can use pull-requests to have another opportunity to review the code changes. It's common to have another developer reviewing code before approving this merge back to develop.

Your Branch Explorer will look like this:


After the develop branch received or integrated some features branches, you can create another branch from it. This new branch will freeze those features and will house bug-fixes relevant to make it stable. For example, you can create this branch with the name release/0.0.1. Later, you merge release/0.0.1 back to develop and lastly to master.

The Gitflow approach using gmaster is awesome. You can clearly see each timeline and how they relate to each other. Your Branch Explorer will look like this:

Final Branch Explorer

Fixing bugs

The process to fix bugs is basically the same of creating new features with the only difference being that you create the branches directly from master. So, if you found a bug in production (remember that master is the production ready version), you should create a branch with the name prefixed with hotfix/, for example hotfix/name-of-the-bugfix.

Later, you bring those hotfixes back to master and to develop, fixing it in the current version (master) and in the future version (develop). :)

Tip: You can add tags to the commit merged back to master with the version of the release. Later, you can even delete the release branch since it was already part of master.

Wrapping up

In this post, we covered how Gitflow works and how great it is using this workflow with gmaster. You can really understand how every branch related to each other. This is very powerful and brings more quality to your projects. Now is your turn; create a new repo and start practicing.

See you in our next post :)

We develop gmaster, a Git GUI with semantic superpowers. It parses the code to really understand how it was refactored and then diff it and merge it as a human would do, matching methods instead of lines.

If you want to try it, download it from here.

We are also the developers of SemanticMerge and Plastic SCM, a full-featured version control.


  1. Hi folks,

    as i stated in one of my mails to you it would be great if gmaster would support branch colors based on name (for example develop branch is always in yellow or hotfix branches are always red)

    this would greatly improve the understanding if you work on several git projects.

  2. I too would like to see if the hot fixes could be in a specific color so its easy to follow.
    Is there a way to make is to that if you click on the specific Feature or branch name that it will check it out automatically, this would be in addition to right clicking the branch name.

  3. Adding support for Gitflow by being able to specify branch names and prefixes and the color for them would be very helpful.
    e.g. master branch name = "main", color = blue, develop branch name "dev", color = purple, feature prefix = "feature/", color = green, hotfix prefix = "hotfix/", color = red, release prefix = "release/"', color = yellow.
    Then when starting a new repo you get the default branches provided and then you can select new feature, new hotfix, new release from the right type of branch and also select merge feature, merge hotfix, merge release and so on.

  4. Write more, that's all I have to say. Literally, it seems as though you relied on the video to make your point. You obviously know what you're talking about, why throw away your intelligence on just posting videos to your blog when you could be giving us something enlightening too read?

  5. Heya i am for the first time here. I found this board and I to find It truly helpful & it helped me out much. I am hoping to give something again and aid others such as you helped me.

  6. Actually no matter if someone doesn't be aware of after that its up to other users that they will help, so here it takes place.

  7. Hi there excellent blog! Does running a blog like this take a lot of work?
    I’ve very little knowledge of coding but I was hoping to start my own blog in the near future.
    Anyways, should you have any ideas or techniques for new blog owners please share.
    I know this is off subject nevertheless I simply wanted to ask.
    Thank you!

  8. I am a 슬롯사이트 expert. I've read a lot of articles, but I'm the first person to understand as well as you. I leave a post for the first time. It's great!!

  9. Hello, I read the post well. 안전놀이터추천 It's a really interesting topic and it has helped me a lot. In fact, I also run a website with similar content to your posting. Please visit once

  10. This is a very good tip particularly to those fresh to the blogosphere. Brief but very accurate information… Appreciate your sharing this one. 스포츠토토