Git Branching Strategy
Branching strategy is a convention that developers follow when using version control system.
Some of the benefits of using git branching strategies are:
- it allows developers to independently work on different features
- it can reduce merge conflicts
- it can help organize and plan releases
There are different branching strategies such as:
- GitFlow
- GitHub Flow
- GitLab Flow
...and more which I will not mention here.
GitFlow
In GitFlow, there are five different branches:
| Type | Description |
|---|---|
| Master | The master or main branch is a branch that reflects a production-ready state (no bugs, well tested) |
| Develop | New features are actively merged into develop branch. Contrary to master branch, develop branch can contain bugs and issues. |
| Feature | This is where new features are being developed. Each developer work on their own feature branch and it must be merged back to develop branch |
| Release | A preparation branch before release. Preparation includes test, documentation and bug fix. Branch off from develop and merged into both master and develop |
| Hotfix | Branch that is used to immediately fix a bug that exist in master branch. Branch off from master and merged into both master and develop |
Benefits of GitFlow is that, it ensures that the master branch is protected from bugs by creating a release branch before develop branch can be merged into master. Creating release branch is also good for version tracking and making softwares that are release based.
Some softwares require support for older versions (ex. Unity) and since GitFlow tracks previous versions, developer can create branch off the previous commit. Some people call it support branch. After branching off from previous version, do some hotfix and leave support branch there for further support.
The downside of GitFlow is that, it can be hard to track bugs in release branch (remember testing is done in release branch). Since releases are created after multiple features are merged into develop branch, there could be too many commits for developer to track.
GitFlow can be an overkill for small scale applications as well, especially in the fields of web development.
GitHub Flow
In GitHub Flow, there are only two types of branches; master and feature branch.
GitHub Flow is ideal for agile methodology since it features frequent releases and fast feedback (feature branch is merged into master straight away). This strategy is also easier to setup devops automation testings and deployment.
The downside is that, master branch is more susceptible to errors. GitHub Flow is also not really suitable for keeping track of different versions.
GitLab Flow
There are two different approaches of using GitLab Flow:
- Using Environment Branch
- Using Release Branch
Environment Branch
When using environment branch, there are 3 different branch types to consider:
- Master branch
- Pre-Production branches
- Production branch
Similar to GitHub Flow, you create feature branches and apply new features to master branch. What is different is that, master branch is considered a staging environment and the real production code lives in a production branch.
When you want to deploy to production, master branch need to go through number of pre-production branches. Pre-production branches can handle things like testing and documentation. Once well tested, pre-production branch can be merged into a production branch.
Unlike GitFlow where develop branch is main working branch, GitLab Flow uses master branch as the main working branch where most changes are applied. This is beneficial since master branch is often the default branch in many of platforms.
Release Branch
When using release branch, there are 2 branch types to consider:
- Master branch
- Release branch
After new features are added to master branch and making sure master branch is as stable as possible, create a release branch that branch off from master. Once release has been made, only update serious bug patches to the branch. When doing a bug fix, do the bug fix in the master branch and apply it to the release by cherry picking. Doing a bug fix in master first and then cherry picking to release branch is called upstream first policy. This make sure that master is always up to date.