Get 40-60% OFF GitKraken Pro!

DIWALI SALE

Get 60-70% OFF GitKraken Pro! Ends In

Days
Hours
Minutes
Seconds
DEEPAVALI SALE

Get 60-70% OFF GitKraken Pro! Ends In

Days
Hours
Minutes
Seconds
OFERTA DÍA DE MUERTOSAHORRA HASTA 70%Oferta Por Tiempo LimitadoComprar ahora
🪔 DIWALI SALE Claim 60-70% Off →
🪔 DEEPAVALI SALE Claim 60-70% Off →

What is the best Git branch strategy?

A Git branching strategy is a set of rules for how your team creates, names, and merges branches. The best strategy depends on how often you release.

Strategy Best for Main branches Release style
Trunk-based development Teams shipping several times a day main plus short-lived branches Continuous
GitHub flow Small teams, web apps main plus feature branches Continuous
GitLab flow Teams with staging and production environments main plus environment or release branches Continuous or versioned
Git flow Products that support several versions at once main, develop, feature, release, hotfix Scheduled, versioned

 

Whichever strategy you choose, GitKraken Desktop shows every branch in a visual commit graph and warns you about merge conflicts before they happen.

Git Flow Branch Strategy

Git flow separates work into five branch types: main, develop, feature, release, and hotfix. It suits products that maintain several versions in production, but its long-lived branches slow down continuous delivery. Learn how Git flow works.

GitHub Flow Branch Strategy

The GitHub flow branching strategy is a relatively simple workflow that allows smaller teams, or web applications/products that don’t require supporting multiple versions, to expedite their work.

In GitHub flow, the main branch contains your production-ready code.

The other branches, feature branches, should contain work on new features and bug fixes and will be merged back into the main branch when the work is finished and properly reviewed.

GitHub Flow Considerations

While working with the GitHub flow branching strategy, there are six principles you should adhere to to ensure you maintain good code.

  1. Any code in the main branch should be deployable.
  2. Create new descriptively-named branches off the main branch for new work, such as feature/add-new-payment-types.
  3. Commit new work to your local branches and regularly push work to the remote.
  4. To request feedback or help, or when you think your work is ready to merge into the main branch, open a pull request.
  5. After your work or feature has been reviewed and approved, it can be merged into the main branch.
  6. Once your work has been merged into the main branch, it should be deployed immediately.

GitHub Flow: Pros & Cons

As with other Git branch strategies, GitHub flow has some highlights and downfalls.

Git Flow example

Custom image inspired by the GitHub Flow Guide.

The Benefits of GitHub Flow

  1. Of the three Git branch strategies we cover in this post, GitHub flow is the most simple.
  2. Because of the simplicity of the workflow, this Git branching strategy allows for Continuous Delivery and Continuous Integration.
  3. This Git branch strategy works great for small teams and web applications.

The Challenges of GitHub Flow

  1. This Git branch strategy is unable to support multiple versions of code in production at the same time.
  2. The lack of dedicated development branches makes GitHub flow more susceptible to bugs in production.

GitLab Flow Branch Strategy

At its core, the GitLab flow branching strategy is a clearly-defined workflow. While similar to the GitHub flow branch strategy, the main differentiator is the addition of environment branches—ie production and pre-production—or release branches, depending on the situation.

Just as in the other two Git branch strategies, GitLab flow has a main branch that contains code that is ready to be deployed. However, this code is not the source of truth for releases.

In GitLab 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.

Using GitLab flow in your release cycle

The GitLab flow branching strategy works with two different types of release cycles:

  1. Versioned Release: each release has an associated release branch that is based off the main branch. Bug fixes should be merged into the main branch first, before being cherry-picked into the release branch.

Git flow for a release cycle

Custom image inspired by image in GitLab Flow.

2. Continuous Release: production branches are utilized to contain deployment-ready code, so code is merged into the production branch when it’s ready to be released.

Benefits of GitLab Flow

  1. When compared to the Git flow branch strategy, GitLab flow is more simple.
  2. GitLab flow is more organized and structured than the GitHub flow branch strategy.
  3. After slight modification, GitLab flow can allow for Continuous Delivery and versioned releases.

Challenges of GitLab Flow

  1. GitLab flow is not the simplest Git branch strategy.
  2. GitLab flow is not the most structured Git branching strategy which can lead to messy collaboration.

The ability to visualize your commits and branches will give you and your team a newfound understanding of your repository’s structure, making daily Git actions more intuitive.

Trunk-Based Development

In trunk-based development, everyone commits to main (the trunk) or merges short-lived branches into it within a day or two. Feature flags hide unfinished work, so main is always ready to release. This keeps merges small and conflicts rare, but it depends on strong automated testing. Read our full guide to trunk-based development.

Branching with AI Coding Agents

When several coding agents work in parallel, each one needs its own branch, and long-lived branches turn into merge conflicts quickly. Short-lived branches checked out in separate Git worktrees keep each agent’s work isolated and easy to review. This favors trunk-based development and GitHub flow.

 

So, which is the best Git branching strategy?

  • If you deploy several times a day: Trunk-based development or GitHub flow
  • If you release on a schedule or support older versions: Git flow
  • If you need staging and production environments: GitLab flow

Most teams start with GitHub flow and add structure only when their release process requires it. Whichever you pick, GitKraken Desktop shows your team’s branches in one graph, so everyone can see what’s in progress and what’s ready to merge

Additional Resources

Table of Contents

Visual Studio Code is required to install GitLens.

Don’t have Visual Studio Code? Get it now.

Team Collaboration Services

Secure cloud-backed services that span across all products in the DevEx platform to keep your workflows connected across projects, repos, and team members
Launchpad – All your PRs, issues, & tasks in one spot to kick off a focused, unblocked day. Code Suggest – Real code suggestions anywhere in your project, as simple as in Google Docs. Cloud Patches – Speed up PR reviews by enabling early collaboration on work-in-progress. Workspaces – Group & sync repos to simplify multi-repo actions, & get new devs coding faster. DORA Insights – Data-driven code insights to track & improve development velocity. Security & Admin – Easily set up SSO, manage access, & streamline IdP integrations.
winget install gitkraken.cli