Git Branching and Modified Git Flow
Git Branching Models
Git branching strategy is a set of rules that describes when to create a branch, merge a branch with others, how to name a branch and similar rules that we should use during the lifetime of a repository. There are several branching strategies and two of them are very popular with different type of usages.
- Gitflow: Branching strategy for scheduled deployment
- Github Flow: Branching strategy for per feature deployment
All branching models should use following basic rules to have a consistent naming in the repository.
- Choose short and descriptive names
- Use hyphens to separate words.
Gitflow
Gitflow is firstly designed by Vincent Driessen in 2010. It has become very popular and used by most of the teams. In 2020, Vincent added a note into his popular blog and suggested to use some other flows if you are doing continuous delivery of software. He is suggesting to use Github flow for these kind of development. Now, we can understand the basics of Gitflow and start to compare it with Github flow.
The main branches
At the core, the development model is greatly inspired by existing models out there. The central repo holds two main branches with an infinite lifetime:
- master : Main branch where the source code of HEAD always reflects a production-ready state. Each time when changes are merged back into master, this is a new production release by definition.
- develop : Main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release.
The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.
Supporting branches
Next to the main branches master and development, there are 3 different supporting branches. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.
The different types of branches we may use are:
- Feature branches : Branches to develop features and merge them to development when it is stable enough.
- Release branches : Branches to support preparation of new production release. We can fix minor bugs and do all required changes before production release.
- Hotfix branches : Branches similar to release but created only when there is a critical bug in a production version.
Pros
- Appropriate for versioned software.
- More organized and structured.
- Allowing to develop multiple feature requests by different developers from different teams.
- Best option when you have static release windows.
Cons
- Complex branching graph.
- Needs a trained team to follow the whole process.
- Time gap between development and release is longer.
GitHub Flow
GitHub flow is a lightweight, branch-based workflow. This flow is optimized for frequent releases in a continuous delivery model and there is only one main branch called master. It is designed for the environments when we are deploying deploying everyday to production or more.
The main branch
In GitHub Flow there is only one main brach.
- master : Main branch where the source code of HEAD always reflects a production-ready state. Anything in the master branch is deployable. The master branch is stable and it is always safe to deploy from it or create new branches off of it.
Supporting branches
All feature or hotfix branches in this flow are created from master branch. Developers are free to give a descriptive name for the branch.
Pros
- Simple to learn and use.
- Best for less experienced developers.
Cons
- Hard to menage several versions at the same time.
- Automated testing is a must.
Modified Git Flow
In Inavitas, we have tried different branching strategies and have been modified them according to system requirements. Now we are using something in the middle of two extremes and this new flow looks better for a product that is woking as SaaS and on-prem in different environments at the same time.
In this new flow, we are keeping similar branches with GitFlow but there are some changes on main and supporting branches. We can go into details of branches now.
The main branches
At the core, the development model is greatly inspired by existing models out there. The central repo holds two main branches with an infinite lifetime:
- master : Main branch where the source code of HEAD always reflects a production-ready state. Each time when changes are merged back into master, this is a new production release by definition.
- release : Main branch to support preparation of new production release. We can fix minor bugs and do all required changes before production release. We should do all these fixes till the next release, that is generally the next day.
- development : Main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release.
Supporting branches
Next to the main branches , there are 2 different supporting branches.
- Feature branches : Branches to develop features and merge them to development when it is stable enough.
- Hotfix branches : Branches similar to release but created only when there is a critical bug in a production version.
How it works?
Steps that we are following in this flow is given below.
- Developers are working on feature branches that is created from development branch and merge it to development when it is ready to release.
- After developer tests on development branch, all micro-services that should be released on that day (because of dependencies between micro-services, releases should be managed with a main version of the product and project versions of the micro-services) should be merged to to release branch that triggers auto-deployments to test environments.
- Then, all automated or manuel tests should run on these environments and product owners should approve the release of the new version of the product.
- Last step is merging all micro-services to master branches that triggers auto-deployments to staging and prod (SaaS) environments.
Tag naming
Commit on some branches must be tagged for easy future reference to this historical version. Tags must be used only for master branches. There should be no other tags for other branches. Tag naming convention should be as given below.
- Tag naming convention for master branch: v1.0.0
Master branch tags should start with v and include MAJOR, MINOR and PATCH versions.
Branch naming for supporting branches
Feature branches
May branch off from: development
Must merge back into: development
Branch naming convention: feature/*
Feature branch name should be the issue ID of the feature like feature/INV-100. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into development or discarded in case of a disappointing experiment.
Hotfix branches
May branch off from: master
Must merge back into: development, release and master
Branch naming convention: hotfix/*
Hotfix branch name should be the issue ID of the feature like feature/INV-100. Hotfix branches arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.
Pros
- There is a middle stage to test before sending to master.
- Useful for micro-services architecture.
- Management of environments with different versions is easier.
- Time gap between development to production could be the same day.
Cons
- Needs a trained team to follow the whole process.
- Requires CI/CD and test automation to decrease the release time.
