Git Branching Strategy

Git, a robust version control system, empowers developers to collaboratively manage and track code changes efficiently. Its branching system enables the creation of independent branches for parallel development, facilitating subsequent merging into the main branch. This capability is pivotal for teams aiming to streamline collaboration and reduce versioning management time. In this blog post, we'll explore three popular Git branching strategies, recognizing the flexibility to adapt and customize these approaches to cater to the unique needs of individual developers and teams.

Pre-requisites

The prerequisites for learning about Git branching strategy can be a basic understanding of Version Control Systems, Branching, and Git. Before learning about the git bisect command, let us discuss them briefly.

A version control system is a tool in software development that tracks the changes in the code, documents, and other important information regarding a certain code base (or project), etc. Git is a version control system that tracks the changes in the code, documents, and other important information regarding a certain code base (or project), etc. Git is free and one of the most widely used version control systems. Apart from that, we must know the concepts of the git log command and the git status command as both of these commands will help us to know the exact scenario of the Git repository.

What is a Branching Strategy?

Every developer has some strategy to follow the entire development process. Git provides developers with numerous strategies that help them in the development process. Git has some predefined workflows that can be used by developers in their project development. The best part is that these workflows are fairly flexible. The developers can modify the workflows according to their own needs.

A question may come to our mind what is a workflow? Git flow can be visualized as a set of rules or guidelines that the developers follow during project development in Git. Some developers also term the Git flow as a branching model since the developers create branches, perform their work, and then push those branches to the central branch. Refer to the image provided below for more clarity.

Need for a Branching Strategy

Whenever we are working as a team we must define some set of rules regarding the development in particular pushing updates to the master branch. The rules not only make the development phase easier but also makes the work of the maintainer quite easy. So, we must agree on some set of rules for example when should we create branches, naming convention, development team, bug fixing team, pulling and pushing strategy, etc. Now, this set of rules or workflow in terms of Git is known as git flow. Git flow is a type of workflow that is not a necessary thing to be adapted but it can make development easier so we should use it.

Git flow use feature branches and various primary branches to maintain the proper project development. Git flow was first published by Vincent Driessen at nvie. The git flow consists of numerous long-lived branches having a large set of commits. As a branch contains numerous commits so a developer can create a branch (for example feature branch or bug-fixing branch) and make commits in that branch only. After the feature development is completed then the developer can push the feature branch to the main branch or central branch. In terms of Git flow, the central branch is also known as the trunk branch because the flow can be visualized as a tree and in a tree trunk is the central component.

Now as we can see that we only push the development branches when the entire development is complete so a feature branch can contain a very large set of commits. These large sets of commits of the feature branch require more collaboration before merging. The merging can be tedious work and thus there is a high risk of deviation from the central trunk branch. Hence there are high chances of merge conflicts. A git flow should ideally be used in the projects that are supposed to have scheduled release cycles and have a continuous delivery as per the best practices of DevOps. We should use this workflow technique when our work has multiple streams and our work is concurrently running.

Common Git Branching Strategies

Let us now look at the various Git branching strategy in detail.

GitFlow

As we have discussed earlier git-flow is a set of commands and rules that helps us to keep the track of feature branches, project releases, and hotfixes. In git flow we have two branches for example main and the develop branch that helps us to store all the records of the project's history. As the name suggests the main or master branch is the branch that contains all the official releases of the project.

On the other hand, there is an extra branch (for example a development branch named develop), this branch will contain all the integrations and development of the features. For easier development and future merging, we can use tags and version numbers for the main branch.

Refer to the image provided below for more clarity.

Now for the development, we should first create an empty development branch in our local repository and push that empty development branch to the central repository. The overall commands for the same are:

As we have discussed, we will use this develop branch to store the entire development history and apart from this, we will use the main branch or the trunk branch to store the abridged versions. Other developers should clone the central remote repository and create a tracking branch for the develop branch.

Let us now learn how we can initialize a git flow and set up our project for the same.

The git flow initialization does not change our repository but it adds various commands so that our development can become easier. So, to add a git flow, we need to navigate to our git repository and use init to initialize the git flow in our repository. The overall command for the same is:

The git flow init is an interactive command. Git will ask some questions like:

These questions are asked for the configuration and some naming conventions of our branch. All the developers of a project should use a common naming convention for better development and easy work.

So far we have discussed a lot about git flow and its usage, let us now learn about the advantages of git flow.

• Git flow is quite convenient to use as it provides us with a lot of commands that speed up our development work.
• We can easily keep track of the entire development phase as well as the previous releases of the project.
• We can easily switch among the branches.
• Git flow promotes a cleaner code base and proper structuring of the central repository.
• Git flow commands can perform multiple works but if we do not use the git-flow then we have to write separate commands for all the tasks.
• Due to the creation of multiple branches, the trunk branch or the central branch does not get affected.
• Git flow manages the overall structuring of branches, release of the projects, features additions, and bug fixing without hampering the production code.

GitHub Flow

If we are working with a smaller team then we should opt for the GitHub flow. This flow is relatively simpler than the GitHub flow strategy. We should use GitHub flow for smaller projects like web applications and websites that do not require a lot of versioning in the development process.

In the GitHub flow, we have the master branch that contains all the codes. We can simply push the content of the master branch as it contains all the production-ready codes. We also have other branches like feature branches and bug-fixing branches. The bug fixing branch is developed to fix a previous or a new bug introduced during the project development. This branch also comes in handy after the project is deployed. On the other hand, the feature branch is used to add a new feature.

Refer to the image provided below for more clarity.

The GitHub flow strategy consists of six principles that we should always follow to ensure good code.

1. The code contained in the main branch or the master branch should be deployable.
2. If you are adding a new feature, then we should create a new branch with the name of the feature that we are working on, Some examples can be the log-in branch or sign-up branch if we are adding a log-in or sign-up integrations.
3. We should always create a local branch for any feature addition or bug fixing. Then we should push our local branch to the remote branch.
4. We should always create a pull request to the remote repository that acts as a request to review and accept our request.
5. Once the reviewer gets the pull request, the maintainer will review our code and once it got accepted then it gets merged to the master branch or main branch.
6. After our code gets merged into the master branch, our code should immediately get deployed.

Some of the major points related to the GitHub flow branching strategy are:

• GitHub flow is the simplest among all the workflow strategies.
• Due to its simpler approach, the GitHub flow strategy is widely used for the Continuous Delivery and Continuous Integration of our ongoing project.
• It should be used for smaller web applications and smaller teams.
• If you are working for a start-up or on a small project, this strategy is best for you.
• One of the major disadvantages of this approach is that it does not support multiple versions of any applications.
• If we follow this strategy, then our production code should always be present on the master branch.
• In this strategy, we do not have the support of dedicated development branches, hence bug fixing in the production code can be a tedious task.

GitLab Flow

The GitLab flow is quite similar to the GitHub flow strategy. The only thing that makes them different is that the GitLab flow strategy provides us with a clearly defined workflow and it also supports the addition of environment branches such as production and also pre-production. We also have the support of release and feature branches that we can opt for depending on the project situation.

The GitLab flow is also similar to the previous two strategies that we discussed earlier. We have the master branch or main branch that contains the deployable code. But, the code is not a source of truth that is ready for release.

There is some difference from the GitHub flow strategy as in this approach, we also have the support of the feature branch that contains the work of newly added features. We can also create bug-fixing branches to work on the bugs so that the production code does not get hampered.

As we have discussed that GitHub flow strategies support the versioning system. We create two types of releases namely version release and continuous release. The version release usually contains the core of the master branch. For bug fixing, we create feature branches or bug branches. Once the bug gets fixed and the code is reviewed they are cherry-picked into the deployed release branch. On the other hand, the continuous release contains the reproduction branches that are utilized to hold the deployment-ready code base. So, first, the code is merged into the production branch, and then it is pushed into the release branch.

Refer to the image provided below for more clarity.

Some of the major points that we should consider while working with the GitLab flow are as follows:

• The GitLab flow strategies are comparatively simpler than the Git flow strategies.
• We can even perform continuous delivery, continuous integration, and version release with the help of this strategy.
• This strategy is more structured and more organized than the GitHub flow strategies. But, it is not one of the simplest strategies.
• It can sometimes lead to messy collaboration. So, we should not primarily use this strategy in the case of large projects.

Trunk-based Development

The trunk-based development strategy is entirely different from the rest of the previously discussed strategies. In the trunk-based development strategy, we integrate our code and development in the shared trunk. This sharing is done at least once a day thus the shared trunk is always ready to be released for production.

The trunk-based development strategy is mainly used in such projects where we make frequent changes and integration to the branches. A project where developers need to fix small bugs and make small changes are best suited for the trunk-based development strategy. This feature helps to avoid long-lived branches and thus avoids merge conflicts in general. In simpler terms, we can say that the trunk-based development strategy avoids the usage of branches and promotes the pushing of changes to the central trunk only.

Refer to the image provided below for more clarity.

Since the trunk is always ready for the feature release, we use the feature flags to help in the development process. So, if we are working on a feature and we do not want to create any branch then we keep on developing the codebase and keep the code wrapped in the feature flag so that the feature is kept hidden until it is fully developed and ready to be integrated.

Some of the major points that we should consider while working with the trunk-based development are as follows:

• The trunk-based development strategy does not require the usage of the branches.
• We use the trunk-based development strategy if we are working on a project that needs frequent changes.
• The merge conflict issue is very less if we use the trunk-based development strategy.
• This strategy offers a quick release of production code as the entire production code is on the trunk.
• If you are working on a small project or you are a junior developer then you should opt for other Git branching strategies like Git Flow, GitHub Flow, and GitLab Flow.

What is the Best Git Branch Strategy?

The trunk-based development strategy is mainly used in such projects where we make frequent changes and integration to the branches. So if you are working on a project where developers need to fix small bugs and make small changes are best suited for the trunk-based development strategy.

Now, if we are working with a smaller team then we should opt for the GitHub flow. This flow is relatively simpler than the GitHub flow strategy. We should use GitHub flow for smaller projects like web applications and websites that do not require a lot of versioning in the development process.

So, depending on the project and environment, we should choose the Git branching strategy so that the production time and workflow are optimized.

Additional Resources

1. Difference between GitLab and GitHub