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:

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 CONTRIBUTING.md, 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:

Integrating

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

  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.

    ReplyDelete