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.
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.
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.