The Complete Guide to Git Branching Strategy: From Git Flow to GitHub Flow

A necessity for collaboration, Git branch strategy

In software development projects, when multiple developers write code simultaneously, conflicts and confusion inevitably arise. “Who modified this code and when?”, “Where is the stable version to be released?” The essential tool to solve these problems is Git.

One of Git's powerful features is 'Branch'. They branch out independently from the main code line, allowing you to safely develop new features or fix bugs. However, if developers create and merge branches at will, the project repository will soon fall into great chaos.

Therefore, a clear ‘Branching Strategy’ is needed that the entire team agrees on and follows. In this article, we will look at the three representative Git branching strategies most widely used in practice and learn how to choose a strategy that suits each team's situation.

1. Git Flow

Git Flow is the most classic and systematic branching model proposed by Vincent Driessen in 2010. It has clear and strict rules, making it suitable for projects with a regular release cycle or large enterprise environments.

Git Flow consists of two main branches that are always maintained and three auxiliary branches that are created when needed and deleted when work is completed.

main branch

• main (or master): The most stable production-level branch that can be deployed to users at any time. Every commit must have a version tag.
• develop: This branch contains the latest code being developed for the next release. All feature development is centered around this branch.

Secondary branch

• feature: When developing a new feature, branch from the develop branch and use it. When development is complete, merge back into the develop branch and delete the branch. (e.g. feature/login)
• release: This is a staging branch for releasing new versions. Once the features to be deployed in the develop branch are gathered, branch the release branch and perform final work such as fixing final bugs and updating metadata. Once done, merge into both main and develop branches and create tags.
• hotfix: Used when a serious bug that needs to be resolved urgently occurs in the deployed production version (main). Branch directly from main, fix the bug, and then merge into both main and develop.

Advantage: The rules are highly structured, minimizing confusion that can arise during large, complex releases. Versioning management is clear. Disadvantage: There are many branch steps, making the flow somewhat complicated and cumbersome. It can feel a bit heavy in modern web service environments that require rapid deployment multiple times a day, such as continuous delivery (CI/CD) or agile environments.

2. GitHub Flow

GitHub Flow is a very simple and lightweight branching model designed by GitHub to compensate for the shortcomings of complex Git Flow. It is ideal for environments with automated continuous deployment or small-scale, web application projects that follow agile development methodologies.

At the core of GitHub Flow is one general principle: "The main branch must always be in a state that can be deployed immediately".

Workflow

1. Create a branch: If you need a new feature or bug fix, create a new branch with an intuitive name from the main branch. (e.g. add-payment-gateway)
2. Add commit: Perform local work on your branch, leave commits, and frequently push to the remote repository (GitHub).
3. Open a Pull Request (PR): Open a Pull Request when the work is somewhat complete or when you need feedback or help from team members.
4. Review and Discussion: Conduct a code review with team members and ensure that the test code passes.
5. Merge & Deploy: Once the review is complete and deemed safe, merge the PR into the main branch. Code merged into main is deployed to production immediately (or through an automated pipeline).

Advantage: The workflow is so simple that anyone can easily understand and apply it. It boasts excellent compatibility with the CI/CD environment and is optimized for fast-tempo development. Disadvantage: Since the main branch is the only reference, there is a risk that critical bugs can easily be exposed to production unless code reviews and automated testing environments (CI) are fully established.

3. GitLab Flow

GitLab Flow is a strategy that compromises the overly complex nature of Git Flow and the overly simple nature of GitHub Flow, making it difficult to manage the deployment environment in multiple stages (staging, pre-production, etc.).

This model, like GitHub Flow, develops through the Feature branch based on the main branch, but is characterized by having separate branches corresponding to the deployment stage (Environment).

For example, in addition to the main branch, you can have a pre-production branch and a production branch. The flow of commits only flows in one direction (downstream). main (development/testing) -> pre-production (staging/QA) -> production (actual deployment)

This approach is useful for teams that need to manage their deployment cycle but do not want a structure as complex as Git Flow, or in environments where immediate deployment is not possible, such as mobile app development, and there are processes such as store screening.

Conclusion: Which strategy is right for our team?

There is no right answer. You should choose an appropriate strategy based on the composition of your team, the nature of your project, and the level of deployment pipeline you have built.

• Solutions and app packages that require clear version management and regular releases: Git Flow
• Web services and agile teams that are deployed frequently every day: GitHub Flow
• When you need to manage multiple deployment environments (Dev, Stg, Prod) but want a simple flow: GitLab Flow

No matter which strategy you choose, the most important thing is that all team members clearly understand and strictly follow the rules and establish a code review culture.