Gitflow with gmaster
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.
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). :)
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 :)
Hi folks,
ReplyDeleteas 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.
I too would like to see if the hot fixes could be in a specific color so its easy to follow.
ReplyDeleteIs 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.
Adding support for Gitflow by being able to specify branch names and prefixes and the color for them would be very helpful.
ReplyDeletee.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.