Git Flow / Git Branching Model
Git Flow is a set of guidelines that developers can follow when using Git. While these guidelines aren't strict rules, they represent a standard for an ideal project, making it easier for developers to understand and navigate the workflow.
Developers refer to it as the Branching Model, where it serves as a central repository for a project. They work on and push their changes to different branches within the main repository.
In a project, various types of branches can exist. Based on the standard branching strategy and release management, the following types of branches may be used:
- Master
- Develop
- Hotfixes
- Release branches
- Features branches
Each branch has a specific meaning and standard. Let’s delve into the purpose and usage of each one.
The Main Branches
Two branches in the branching model are considered the main branches of the project. These branches are:
- master
- develop
Master Branch
The master branch is the primary branch of the project, containing the entire history of final changes. Every developer should be familiar with the master branch, as it holds the source code at HEAD, always reflecting the project's final version.
Your local repository’s master branch is always synchronized with the master branch of the remote repository.
It's advised not to alter the master branch because changes you make can impact everyone else in the group project, quickly leading to merge conflicts.
Develop Branch
It runs parallel to the master branch and serves as the main branch of the project, containing the latest development changes for the next release. This branch holds the final source code for the release and is also known as the "integration branch".
When the develop branch reaches a stable state and is ready for release, it should be merged into the master branch and tagged with a release version.
Supportive Branches
The development model requires various supporting branches to manage parallel development, track features, facilitate quick fixes and releases, and address other issues. These branches have a limited lifespan and are deleted once they are no longer needed.
The various types of supporting branches we might use are as follows:
- Feature branches
- Release branches
- Hotfix branches
Each of these branches serves a specific purpose and has designated merge targets. They are crucial from a technical perspective.
Feature Branches
Feature branches, also known as topic branches, are used to develop new features for the next version of the project. These branches have a limited lifespan and are deleted once their feature has been merged into the develop branch.
Release Branches
A release branch, created by senior developers, is used to support a new version release and includes a set number of feature branches. This branch should be deployed to a staging server for testing.
Developers can perform minor bug fixes and prepare release metadata on this branch. Once these tasks are completed, it can be merged with the develop branch.
Once all the targeted features are completed, the release branch can be merged with the develop branch. Some common standards for the release branch include the following:
- Typically, a release branch is created by senior developers.
- The release branch will include a predefined set of feature branches.
- The release branch should be deployed to a staging server for testing purposes.
- Any bugs that need to be fixed must be addressed in the release branch.
- The release branch must be merged back into both the develop and master branches.
- After merging the release branch with the develop branch, it must be tagged with a version number.
Hotfix Branches
Hotfix branches are similar to release branches, as both are created for a new production release.
Hotfix branches are created in response to urgent issues. If a critical bug is found in a production version, a hotfix branch may be created. Once the bug is fixed, the branch can be merged into the master branch and tagged with a version number.
