There is already a lot of contention and debate around using Git Flow vs GitHub Flow branching model since there are trade-offs to using either. This is a concise summary.
- For teams who must make formal releases on a longer time scale (a few weeks to a few months between releases) and be able to perform hotfixes, maintenance branches and other things that emerge from shipping so infrequently, git-flow makes sense.
- It is advisable to choose something simpler, like GitHub Flow, for organizations who have established a culture of shipping, push to production frequently (if not daily), and are constantly testing and deploying.
However, comparing Git Flow vs GitHub Flow is not the goal of this report. The purpose of this is to promote the use of the most straightforward Branching Model that will work for all potential project teams. The “Branching Strategy” and the GitHub “Workflows” across projects need to be standardized immediately utilizing the “Perspective” method. Utilizing the Git Flow model is recommended.
Key Benefits of Git-Flow Branching Model:
- Parallel Development:
GitFlow is useful because it isolates new development from completed work, which makes parallel development simple. Future branches are used to work on new features and non-emergency bug fixes, and they are only merged back into the main body of code if the developer is satisfied that it is ready for release.
Despite the possibility of interruptions, all you must do to go from one task to another is commit your modifications and then make a new feature branch for it. Check out your original feature branch once the task is complete to pick up where you left off.
- Collaboration:
Feature branches also make it simpler for two or more developers to work together on the same feature because each feature branch only contains the changes required to make the new feature functional, that makes it very simple to view and understand what each collaborator is doing.
- Release Staging Area:
As the new development is completed, it gets merged back into the develop branch, which is the staging area for all completed features that haven’t yet been released. So when the next release is branched off to develop, it will automatically contain all of the new stuff that has been finished.
- Support For Emergency Fixes:
GitFlow supports hotfix branches branches made from a tagged release (or master branch). You can use these to make an emergency change, safe in the knowledge that the hotfix will only contain your emergency fix. There’s no risk that you’ll accidentally merge a new development at the same time.
Branches Explained:
Main Branches:
- Master – this branch will confirm stable code running in production. Projects should consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
- Develop – this is often referred to as the “integration branch”. It is also the starting point of the feature. When the source code in the origin/develop branch reaches a stable point and is ready to be released, projects should create a release branch.
Supporting Branches:
- Feature – every time there’s a new feature to be implemented, a new branch needs to be created following this pattern feature/<Jira_storyID>-<summary>. Must merge back into the develop branch.
- Release – ideally this branch should be used for UAT releases. The key moment to branch off a new release branch from develop is when the develop branch reflects the desired state of the new release. Should be merged to the master branch once a release (or UAT) is complete and all UAT fixes should be backward merged into develop.
- Bugfix – a bugfix branch should be used for fixing UAT bugs. They are branches from release branches and once the UAT bug is fixed, change is merged back to the release branch.
- Hotfix – a hotfix branch is a lot like release branches and feature branches except they are branched from master instead of develop. When a critical bug in a production version must be resolved immediately, a hotfix branch needs to be branched off from the corresponding tag on the master branch that marks the current production version.
Supporting Branches – Prefix Conventions:
- Feature -> feature/**
- Release -> release/**
- Hotfix -> hotfix/**
- Bugfix -> bugfix/**
Conventions of Git-Flow Approach:
- Using short lived branches.
- When a feature is completed a Pull Request is created to merge with develop branch. This allows code review and integration tests to be verified before merging.
- The new feature to be developed needs to follow similar syntax like feature/<Jira-storyID>-<summary>
- The hotfix to be developed needs to follow the syntax like hotfix/<IssueID>-<summary>
- The release to be created needs to follow the syntax like release/<version>
- The develop branch is the main developer’s integration branch.
- The master branch always reflects the current code from production.
SDLC Overview:
Development Phase:
New development (new feature, sprint bugs) is built into feature branches. Feature branches are branched off from develop branch, and finished features and fixes are merged back into the develop branch once ready.
UAT and GO Live Phase:
When it is time to make a release, a release branch is created from develop. The code in the release branch is deployed onto UAT. UAT bugs are recreated and fixed in the bugfix branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until customer is happy that release is good enough to release into production for end users.
When the release is finished, the release branch is merged into master. And backward merged into develop to make sure that any changes made in the release branch aren’t accidentally lost by new development.
Post GO Live Phase:
The master branch has the production code. Therefore, it is important to tag the master branch with version of the production release. The only commits to master are merges from release branches and hotfix branches.