🔭Are We Using Git Right? A Look at 3 Common Branching Strategies

Hello, and welcome to your Aiden's Lab Notebook.

Git is an excellent distributed version control system, but when team members use it in their own ways, it can lead to problems like code conflicts or difficulty in managing history.

It takes more than just knowing Git commands; you need clear rules and procedures that the entire team can agree on and follow. Without an agreement on when to create which branches, and when to merge and deploy, Git might just become a glorified file backup tool.

So, how should we be using Git? This is where Git branching strategies come into play.

By the time you finish reading this article, you'll be able to find a Git branching strategy that's right for your team.

Working on a project alone? Don't worry. I'll also recommend a Git branching strategy that's helpful for managing projects as a solo developer.

Why Git Branching Strategies are Crucial for Project Management

A Git branching strategy is a methodology that defines the rules and procedures for how a team develops, integrates, and deploys code. It serves as a foundation for systematically managing code changes and ensuring project stability. That's why a good Git branching strategy...

• Increases the stability of code integration and facilitates parallel development.

• Helps establish a code review culture, contributing to improved code quality.

• Can be naturally integrated with Continuous Integration (CI) and Continuous Deployment (CD) pipelines.

There are three main types of Git branching strategies:

• Git Flow

  • A systematic strategy that utilizes core branches (main, develop) and supporting branches with clear purposes (feature, release, hotfix).

• GitHub Flow

  • A strategy suited for rapid deployment without complex rules, keeping the main branch in a deployable state at all times.

• GitLab Flow

  • A flexible strategy that takes the simplicity of GitHub Flow and allows for the addition of branches for environment-specific deployments (e.g., pre-production, production) or release branches for specific versions as needed.

Let's take a closer look at how each strategy works, along with its pros and cons, to help you find the right fit.

Git Flow

If you've ever searched for Git branching strategies, you've probably seen a diagram like the one below. This is a graph representing Git Flow.

Don't worry if the diagram looks complex; you don't need to understand everything in it right now.

What we need to focus on is that the bolded master (or main) and develop branches are the core branches of Git Flow.

How Git Flow Works

At the heart of Git Flow are two persistent core branches (main, develop), supported by auxiliary branches (feature, release, hotfix).

• main branch

  • Contains the stable version of the code that has been deployed to production.

  • Manages each release version via tags.

• develop branch

  • Contains the latest code under development for the next release.

  • Serves as the base for all feature development.

• feature branch

  • Branched off from develop with a name like feature/{feature-name} when a new feature or improvement is needed.

  • Each feature is developed in its own isolated feature branch and then merged back into develop upon completion.

  • The feature branch is deleted after being merged.

• release branch

  • Branched off from develop with a name like release/{version-number} when enough features for the next release have been integrated into develop.

  • This branch is used only for final testing, documentation, and bug fixes discovered during this process.

  • Once ready for deployment, it's merged into both main and develop.

  • The release branch is deleted after being merged.

• hotfix branch

  • Branched off from main with a name like hotfix/{bug-issue-number} to address urgent bugs in the production code.

  • After the work is done, it's merged into both main and develop.

  • The hotfix branch is deleted after being merged.

Pros and Cons of Git Flow

As we've seen, Git Flow involves a systematic and clear process of branching and merging. Here’s a summary of its pros and cons.

Pros:

• Reduces confusion in code management and allows for systematic version control, even in large-scale projects where multiple developers work on various tasks simultaneously.

• Provides a clear process for preparing stable releases via the release branch and for quickly addressing urgent production issues via the hotfix branch.

Cons:

• The variety of branch types and their specific merging rules can feel complex for teams new to the strategy.

• The separate release preparation process via the release branch can be cumbersome and slow for modern web services where deployments happen daily or even more frequently.

• The complexity of branch management can make it difficult to fully integrate with Continuous Integration (CI) and Continuous Deployment (CD) pipelines.

GitHub Flow

GitHub Flow emerged as a branching strategy to minimize the complexity of Git Flow. Just by looking at the diagram below, you can see it's much more streamlined than Git Flow, right?

How GitHub Flow Works

The core principle of GitHub Flow is to keep the main branch stable and always ready for production deployment. All development work starts from the main branch and undergoes thorough testing and review before being merged.

All new work, whether it's adding a feature or fixing a bug, is done in a branch called a Feature Branch. These feature branches are typically named to describe the work being done (e.g., fix-login-bug, add-user-profile).

Once the work in a feature branch is complete, it is merged into the main branch. Since the code in main is the production-ready code, it’s well-suited for setting up a CI/CD pipeline that triggers automatically upon merging.

Pros and Cons of GitHub Flow

Being significantly simpler than Git Flow, GitHub Flow has very clear advantages and disadvantages.

Pros:

• Uses a minimal number of branch types (main and feature branches), reducing the overhead for adoption and training.

• Enables a rapid development and deployment cycle, with multiple deployments per day possible, since code merged into main is immediately deployable.

• Highly conducive to building and automating CI/CD pipelines.

Cons:

• Since the main branch always represents the latest deployed version, it's not well-suited for traditional software release models that require managing a specific version of code separately or maintaining multiple versions simultaneously.

• There is no separate, defined procedure for handling hotfixes, so they must be dealt with on a case-by-case basis.

GitLab Flow

GitLab Flow was designed to maintain the core principle of GitHub Flow—'main branch-centric development'—while allowing for the flexible introduction of additional branches as needed by the project. In other words, it's a strategy that aims to combine 'simplicity' with 'systematic management'.

How GitLab Flow Works

First, here's how GitLab Flow is similar to GitHub Flow:

• main branch

  • Contains the stable code deployed to the production environment.

• feature branch

  • Where all new feature development and bug fixes occur.

  • Branched off from main and merged back into main upon completion.

And for more systematic code management, GitLab Flow allows for the following branches:

• Environment Branches (e.g., pre-production, production)

  • Correspond to each deployment environment, like staging or production.

  • You merge code from main to a pre-production branch to deploy to a staging environment. After thorough testing, you merge from pre-production to the production branch to deploy to the live environment.

• release branch

  • For projects requiring regular releases or specific version management, a branch like release/{version-number} can be created.

  • Once stabilization work and bug fixes for that version are complete, it is deployed to production and merged into the main branch.

Pros and Cons of GitLab Flow

GitLab Flow, which tries to capture the 'simplicity' of GitHub Flow and the 'structure' of Git Flow, has the following pros and cons.

Pros:

• Maintains a concise basic workflow while allowing for flexible operations through the introduction of environment or release branches.

• When used within the GitLab platform, it allows the entire development lifecycle to be linked to issues for effective tracking and management.

Cons:

• It has a higher complexity than GitHub Flow.

Which Git Branching Strategy is Right for My Project?

We've now explored the workings, pros, and cons of these three Git branching strategies. I've also summarized the scenarios where each strategy is a good fit, which should help if you're looking for the right one for you.

When Git Flow is a good fit:

• For teams with clearly defined development processes, where multiple teams or many developers are involved and have distinct roles.

• For developing softwares that require maintaining multiple versions simultaneously or needs clear version management.

  • Examples: Embedded software, libraries, etc.

When GitHub Flow is a good fit:

• For solo developers who want to record their development history while implementing features rapidly.

• For small teams following agile methodologies.

• For developing web services, SaaS, or mobile apps where continuous feature improvement and user feedback are crucial.

When GitLab Flow is a good fit:

• For teams that have been using GitHub Flow but now need to manage multiple release versions or various deployment environments.

• For teams using the GitLab platform who want to increase the visibility of their overall workflow.

Wrapping Up

We've now covered three of the most representative Git branching strategies. What do you think? Have you found a Git branching method that seems useful or interesting to you?

Of course, you don't have to pick one of these strategies and stick to it rigidly.

The ultimate goal of a Git branching strategy is to manage your project more effectively. This means you can flexibly adopt and adapt parts of a strategy, as long as your team agrees on the changes based on your project's needs.

I hope this has been helpful for those who were using Git but were curious about a more structured approach to branching, or for anyone looking to efficiently manage a new project.

I'll be back next week with another interesting topic. Thank you.

✨Enjoyed this issue?

How about this newsletter? I’d love to hear your thought about this issue in the below form!

👉 Feedback Form

Your input will be help improve Aiden’s Lab Notebook and make it more useful for you.

Thanks again for reading this notebook from Aiden’s Lab :)