Cover image

Branch strategies

7/1/2023, 2:49:00 AM

tags: tech git

What is GitFlow?

source: https://www.gitkraken.com/learn/git/git-flow

Gitflow is a branch strategy which is from A successful Git branching model by Vincent Driessen. There are 2 types of branches in GitFlow:

  1. Main branches

    Main branches are long living branches.

    • main (master)

      It's always in production-ready state in main branch.

    • develop

      This include haven't released features.

  2. Supporting branches

    Supporting branches are for specific purpose.

    • feature

      Branch off from develop and merge back to develop. This is where to develop new features.

    • release

      Branch off from develop and merge back to develop and main. This is where for releasing the software.

    • hotfix

      Branch off from main and merge back to main and develop. This is where for fixing some critical issues in released software.

GitFlow includes various types of branches makes it easier to organize development. When the software supports multiple versions release, it could be easily manage it. However, Continuous Delivery or Continuous Integration settings in this flow would be complex.

During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

A successful Git branching model by Vincent Driessen.

What is Github Flow?

source: https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy#github-flow-pros-cons

In contrast, GitHub flow is pretty simple. There's only one long living branch, main. Any other feature branches out from main and merge back to main when the feature is done. It could be easily set Continuous Delivery or Continuous Integration on main branch.

Sometimes, each feature has its own scheduled release date. In this case GitHub flow might be hard to satisfy this kind of situation. For example, there are feature A and feature B and feature A is merged back to main branch earlier than feature B while feature B's scheduled release date is earlier than feature A.

What is Gitlab Flow?

source: https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy#using-gitlab-flow-in-your-release-cycle

While there are many environments in different stages, it would be hard to manage it by GitHub flow. Gitlab flow, based on GitHub flow, have multiple long living branches for different purposes or different environments. That's said if you have staging environment, develop environment and production environment. You could create staging and production branches and use main branch for develop environment. Once some features are ready to staging environment, send a merge request from develop branch to staging branch.

Reference