Gitflow with gmaster

Gitflow with gmaster

Thursday, March 15, 2018 1 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 README.md 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:

And in your GitHub branching view, something like this:

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 CONTRIBUTING.md, add some information to it and commit those changes. The Branch Explorer will look like this:

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

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:

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 :)