Gitflow is a branching model first introduced and popularized by Vincent Drissen in 2010. This post is covering the manual part of managing the branching without any integration of now available workflows like GitFlow. If your project is in the initial stage of implementing the dev-ops and looking forward to maintaining the explicit versions for your code then still, GitFlow branching mode is relevant for the developers and most useful in order to step towards full-fledged dev-ops.
In order to achieve a matured Continuous Delivery practice, there are better and advanced workflows available such as Github Flow. I personally to go aheat with Gitflow path first to advance towards workflows.
I have implemented and practiced GitFlow on many projects and have helped the entire team. Practice of GitFlow also helped in many ways to instill the importance of automated dev-ops or continuous delivery for your code.
01. Environment and Git branches mapping
Purposefully, I am considering simple environment setup and relative branches. But you can enhance this branching model for even complicated environment too.
|1||Development||develop-branch||This is an integration branch heavily used by Developers|
|2||QA / Test||release-branch||Release branch can be pointed to 01test environment which can further be used as an UAT environment too.|
|3||Production||release-tag||Isolated code snapshot in the form of TAG can be pointed to 01live environment.|
02. Gitflow by Vincent Driessen
GitFlow is introduced by Vincent Driessen widely utlized by open source projects. GitFlow is followed many project across the globe and highly recommended by dev ops teams as well.
02.01 Naming Conventions
|1||Primary||main||This is the MASTER branch. We are purposefully using main instead of master.|
|2||Development||develop||This is the DEV branch. Mainly used by developers as an integration branch.|
|3||Features||feature/JIRA-xxxx||This is the FEATURE branch. Jira ticket id can be made mandatory and every commit to that branch will need to have the Jira ID in it.|
|5||Tags||release-tag||Xx.xx can be considered as a version system and can be agreed upon by all developers. E.g Lets consider we just done Sprint # 7 then release branch could be named as [release/r-07.01]|
02.02 Let's simplify it
Let's try to simplify it in the form a single flow of managing the branches moving the change from the develop branch to a release tag. Here are some the naming conventions which we will be using in the flow diagram.
- Each branch scope has a color
- Digits specified in the colored square-box represent the step (sequence)
- Red : Main Branch [master]
- Blue : Development Branch [develop]
- Green : Feature Branch [feature/f-xx.xx]
- Orrange : Release Branch [release/r-xx.xx]
- Cyan : Tags [tag/t-xx.xx]
- Grey : Hotfix [hotfix/h-xx.xx]
- Letters in the colored circles represent the branch names.
02.02.01. Quick Steps
Here are the quick steps which we can consider
- Step - 1 : Create [develop] branch from [master]
- Step - 2 : Create the feature branches specific to each jira story/ticket
- Step - 3 : Complete the implementation part in feature branches
- Step - 4 : Once the implementation part in feature branches is over it can be merged with [develop] branch through PR
- Step - 5 : ensure all the merged feature branches are working properly
- Step - 6 : Once all the features for a particular sprint are over and merged in the Dev [develop] branch, then the Release Branch [r-sxx-xx] can be created.
- Step - 7 : ensure functionality in Release Branch is working properly
- Step - 8 :Merge release branch [r-sxx-xx] with Master Branch [master]
- Step - 9 :Create the Tag [t-sxx-xx] from Master Branch [master]
- Point this Tag to the PROD environment.
- Step - 10 : In the event of the neccessity of HOTFIXES, hotfix branch [hotfix/h-xx.xx] can be created from Master [master] and merged back to Master [master] and Dev [develop].
02.02.02. Interdependent Tasks
There could be a case of interdependent tasks which needs to be worked out before that code is merged with the Dev [develop] branch.
- Create a parent-feature branch from Dev branch [develop] for the parent task (it could be a single epic or multiple stories or a single story and multiple sub-tasks).
- Create a child-feature branch from the parent-feature branch.
- The child-feature branch can be merged with the Parent-feature branches by developers only (you can also consider getting this merging done through PR).
- Once dependent tasks are complete, merge parent-feature-branch with develop branch only through PR.
While implementing GitFlow or workflow for the projects. I have observed certain questions and reservations and let's try to address those.
Why do we need to complicate things when we are already managing our code perfectly with Git?
Perhaps you are managing it perfectly which is known to you only and being considered perfect only from your angels. It's always best to have something as an Industry Standard so many people know about it. This simple thought process makes a big difference for any new team member's onboarding and managing the decentralized projects.
Why only GitFlow and can't we have our own branching model which could be as efficient as GitFlow?
You can but - but reconsider - why to reinvent the wheel. There is a lot of documentation available for GitFlow and is widely used and practiced. In Fact some of the workflows (such as GithubFlow) do conceptually relate to GitFlow. Using something time-tested does help in long run and saves the time.
Why can't we just use GitWorkflows instead of GitFlow?
That's the good questions. I have used Workflows too, at times it needs a dedicated DevOps engineer in the team too. Workflows are always the best and reliable way to implement Continuous Delivery. I always consider GitFlow as a first step in order to automate the DevOps or release management processes.
Do we need to delete the Feature Branches once merged with the develop branch?
You can delete it - in case you want to keep things clean. If you look at the subscription plans from GitHub, GitLabs or Bitbucket - they hardly care about the storage. I have never cared about deleting the feature branches.