Git Branching Strategy

 

Introduction

Every Organization would want its development and release lifecycle to be faster, agile, and with zero defects in Production. In this situation, we cannot afford to waste time with “Defect/Bugs/Vulnerability" which leads to re-design, re-work, and refactoring.

When we have a large team of developers working simultaneously, coordination between the developers plays a major role in which Source Code Management, Branching, and Merging of code plays an important role. Therefore, it is very important that teams need to have a proper streamlined process in place to implement multiple changes at once. This is where having an efficient branching strategy becomes a priority for these teams.

Challenges with Code Management.

·       Version Control: Keeping track of different versions of code, especially when multiple developers are making changes simultaneously, can be challenging.

·       Code Duplication and Merge Conflict: With multiple developers working on the same codebase, there is a risk of duplicating code or introducing a conflict.

·       Collaboration: Sharing code between team members and ensuring everyone are having the latest version of the code can be difficult, especially for teams working across multiple locations.

·       Scalability: As the size of the codebase and the team grows, managing and organizing code becomes more complex.

What is Source Code Management?

Source code management is potentially your most valuable asset in the CI/CD Pipeline and the foundation for building up and planning your CI/CD platforms. It enables multiple software developers to track, manage, and organize code.

There are several players in the market, first decision point is whether to go with an open-source solution for managing the code or use the Managed Solution provided by Cloud Vendors.

There will be several checkpoints which needs to be considered when evaluating a source code management tool such as:

·       Strong Security controls.

·       Highly available.

·       Consistent High throughput.

·       High Durability.

·       Features.

·       Options for integrations with numerous other tools.

·       Costing.

Evolution of Source Code Management

What is a Branching Strategy?

Before we jump into Branching Strategy, Let us understand what is a Branch and Merge

Branches: When working in a team to avoid conflicting with each other's changes, developers create their own copy of code Merge the main codebase which is called as BRANCHES. This enables stability among critical branches while allowing complete freedom for developers to commit any changes they need to meet their goals.

 

 Merge: The process of merging the changes done by the individual developers into the stable/master branch is called MERGING. A Pull request is triggered when the code from the feature branch is ready to be merged with the stable/master branch. This ideally also involves one more reviewer who will validate the code and later approve/reject the request.

 

A “branching strategy” for your source code management refers to the strategy a software development team employs when writing, merging, and shipping code by which work will not overlap and affect the codebase.

 

Factors need to be considered while deciding the Branching Strategy

·       Project Requirement.

·       Business Requirement.

·       Team Size.

·       CI/CD Tools that are leveraged.

·       Frequency of deployment.

Types of Branching Strategy:

·       Trunk Based Development.

·       GitHub Flow. [Feature Branching]

·       Git Flow.        [Branch-based development]

·       GitLab Flow. [Release Branching]

Trunk Based Development:

With this strategy, software developers merge small frequent updates to a master/single branch called TRUNK. Developers can clone/pull the code from the master branch, create a local repository, and push the code to the master branch once work is completed.

Branches in this strategy are short-lived and merged as frequently as possible. This makes the process of merging easier.

It suits for smaller teams where all commits straight to TRUNK with a pre-integration step of running the build first. 

Pros:

·       Most Simple branching strategy.

·       Most suitable for Continuous Integration.

·       Most suitable for the small teams.

Cons:

·       Lack of dedicate branches makes GitHub flow more likely to bugs in production.

·       This Git branch strategy is unable to support multiple versions of code in production at the same time.

·       Not adequate when it needs the release plans.

GitHub Flow Branching Strategy:

It’s a relatively simple that allows smaller team that don’t require supporting multiple versions, to expedite their work. In this Master branch contains your Production -Ready Code. The other branches, feature branches will contain new feature & Bugs fixes. It will be merged back to main Master branch when the work is finished.

It follows 6 principles:

§  Any Code in the Master branch should be deployable.

§  Create new branches from the main branch for any new work, such as feature/add-new-module

§  Commit new work to your local branches and periodically push work to the remote.

§  Create a Pull request, when you think your work is ready to merge into the main branch.

§  After reviewed and approved, it can be merged into the main branch.

§  Once your work has been merged into the main branch, it should be deployed immediately.

Pros:

·       Most Simple branching strategy.

·       Most suitable for Continuous Delivery and Continuous Integration.

·       Most suitable for the small teams.

·       Ideal when there is a need to maintain single versions in production.

Cons:

·       Lack of dedicate branches makes GitHub flow more likely to bugs in production.

·       This Git branch strategy is unable to support multiple versions of code in production at the same time.

·       Not adequate when it needs the release plans

Git Flow Branching Strategy:

The main idea behind the Git Flow Branching strategy is to isolate your work into different types of branches [Multi-Branch Approach] which involves creating multiple levels of branching off of master. There are 5 different branch types in total:

·       master.   [Primary Branch Contains Production Code. PERMANENT BRANCHES]

·       develop.  [Primary Branch Contains Pre-Production Code. PERMANENT BRANCHES]

·       feature-*.   [Supporting Branch used for new feature release for upcoming release. SHORT LIVED BRANCHES]

·       release-*.   [Supporting Branch used to prepare a new production release. SHORT LIVED BRANCHES]

§     hotfix. -*    [Supporting Branch used to act immediately upon undesired status in master. SHORT LIVED BRANCHES

Pros:

·       The various type of branches makes it easy to organize your work.

·       Leads to efficient testing.

·       Ideal when there is a need to maintain multiple versions in production.

Cons:

·       For complex projects/products, this model could overcomplicate and slow down the development process and release cycle.

·       Long development cycle.

·       Not recommended when only single version in production is required.

GitLab Flow Branching Strategy.

 

It is similar to the GitHub flow branch strategy; the main differentiator is the addition of environment branches—i.e., production and pre-production/release branches. This branching strategy has a very clearly defined workflow. The main difference between GitLab Flow and GitHub Flow are the environment branches.

 Here Production branches are will always contain deployment-ready code. Code is merged into the production branch only when it’s ready to be released.

In this flow, the feature branch contains work for new features and bug fixes which will be merged back into the main branch when they’re finished, reviewed, and approved.

Pros:

·       It is Simple when compared to Git Flow branching Strategy.

·       More Organized than the GitHub Flow branching Strategy. 

·       Best suited when it needs to maintain a single version in Production

 

Cons:

·       Not a structured Git Branching Strategy, which can lead to conflicts in collaboration.

Conclusion:

Using a well-defined branching strategy is important for software development teams to effectively manage code changes, ensure collaboration, and deliver high-quality software products. Different branching strategies provide various benefits and can be used based on the project / team's needs. It can also help to reduce the risk of errors and conflicts in code and provides a clear structure to manage multiple versions of the codebase. By adopting a branching strategy that is appropriate for their project, teams can better manage their code, improve collaboration, and streamline the development process.