Introduction
Here in this tutorial I am going to explain what are the different branching strategy in Git repository, I will talk about different git branching workflows and how to work with different branches in Git repository. You might have heard of or seen different branches in Git repository, such as, master, develop, feature, release, etc. Among these branches there are some long running branches, for example, master, develop. Some branches are short-lived and these branches are used to develop a small feature or change, for example, feature branch. A feature branch is also known as topic branch.
Long Running Branches
Long running branches are those branches where more stable codes are committed and commit happens very unfrequently unlike the feature or topic branches where developers commit very frequently. Long running branches, such as, master, develop, last for long time because developers commit into these branches once they have fully tested the functionality into topic branches in dev or sit environments. Even master branch is more stable than develop branch because the code changes are merged into the master branch only when a release has been occurred from develop branch in more higher environment (production environment). Sometimes, a release branch may also be created from develop branch for releasing into the production environment.
Maintaining stable code in only one branch (master) will give developers benefits in terms of if anything goes wrong in the feature or develop branch, developers will be able to restore code from the stable branch. The develop branch may be used for testing in uat environment. UAT environment is the environment where if all tests are passed then your application will be approved for release into production environment.
Please note that the branch naming convention or branching strategy again depends on your team. There are no such hard and fast rules which you need to follow but these naming conventions are standard naming conventions.
It’s also not always necessary that your develop branch will always contain stable code but probably in subsequent commits your develop branch may not get stable code. The reason behind develop branch becoming temporarily unstable is that many developers commit their code very frequently from different feature or topic branches.
Some larger projects may have proposed or pu (proposed update) branches that can have several integrated branches that may not be ready to go into the master branch.
The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them. Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.
Short-lived Branches
Short-lived branches are useful for any size of projects. Short-lived branches (for example, feature branch or topic branch) are generally created for a single particular feature or related work. This type branch is too expensive to be created or merged in VCS. But, in Git, it’s common to create, work on, merge, and delete feature or topic branches several times a day.
Probably you create feature branches from develop branch and commit few changes into the feature branch and merge the feature branch into the develop branch and later you delete the feature branch. This technique allows you to context-switch quickly and completely, because your work is separated into a different branch where all changes in that have to do with a particular topic or feature. During code review, it is easier to check what has happened in that branch. You can keep the changes in this branch for any time (there is no time limit) and merge them back to the higher branch as and when required regardless of the order in which they were created or worked on.
Git Branching Strategy
Here I am going to give some general explanation about what branches are created for what purpose. The following diagram shows what branches have been placed in the git workflows.
In the above image the master branch is the most stable branch that can be used as an integration branch for develop branch. The master branch or main branch stores the official release history.
The develop branch usually serves as an integration branch for feature branches.
Each new feature should reside in its own branch and instead of branching off of master branch, feature branches use develop branch as their parent. When a feature completes, it gets merged back to the develop branch. The feature branch should never interact directly with master branch and feature branch us created off to the latest develop branch.
Now developers are developing features and merge them back to the develop branch and develop branch gets enough features for a release. So, a release branch is forked off of develop branch. Once this release branch is created for next release cycle, no new feature can be added after this point, and only bug fixes or other release-related tasks should go into this branch. Once release happens, the release branch gets merged into the master branch and tagged with a new version. In addition, this release branch should be merged back to the develop branch as well, because since its creation, the release branch might have progressed with other changes which might not be available in the develop branch.
Having a dedicated release branch creates a well-defined phases of development, and it also makes possible for one team to polish the current release while another team continues working on new features for the next release.
Hotfix branches are a lot like develop and feature branches except they are based on master instead of develop branch. Hotfix branches are used to quickly patch production releases.
The hotfix branch is the only branch that is forked off of master branch. As soon as fix is deployed or complete, the hotfix branch should be merged into both master and develop (or the current release branch if available) branches.
Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle.
Overall Summary
The overall flow of the git branching strategy can be summarized as follows:
- A develop branch is created from master branch
- A release branch is created from develop branch
- Feature or topic branches are created from develop branch
- Once feature is complete, it is merged into the develop branch
- Once release is done, it is merged into both master and develop branches
- For any issue, a hotfix branch is created from master branch
- Once hotfix is done, it is merged into both master and develop branches
Remember, in this tutorial, the naming conventions for branches are used to demonstrate the Git workflow and branching strategy.