Git Flow, GitHub Flow, GitLab Flow, Trunk Based Development

@ Git

Introduction

In maintaining projects of varying scales, I wanted to understand the pros and cons of different Git branching strategies to select suitable ones for development. Currently, the strategy I most frequently encounter is Gitflow, but I have found this approach to be less flexible for small-scale projects (fewer than 5 people). Coincidentally, there is an opportunity to try out other strategies on brand new projects and observe the pain points of existing branching strategies:

  • For simple projects just starting out, the process is relatively overly complex.
  • Too many long-lived branches make it difficult to have a definitive version in development.
  • Concerns arise whether merging larger branches might introduce new issues.

Some people love GitFlow, while others dislike it greatly. In this article, I aim to explore and analyze the advantages and disadvantages of different strategies.

Gitflow

Gitflow is a comprehensive branching strategy designed to cover various scenarios. Developers create feature branches based on functionalities and merge them into the develop branch upon completion. When a release is needed, a release branch is created for testing and adjustments, which is eventually merged into the main branch for official release (tags can be added for version labeling).

If urgent issues arise post-release, a hotfix branch is created from main to address the problems. Once the fixes are complete, the changes are merged back into the main branch, and a copy is also merged into the develop branch.

  • Advantages:
    • Predictable release cycles: The development, testing, and release cycles are very clear, making it suitable for teams with regular development and release rhythms.
    • Enhanced collaboration: By separating specific environments with branches that have defined responsibilities, it suits large teams and collaborative parallel development across multiple teams.
    • Effective handling of multiple product versions: With release and hotfix branches, Gitflow allows teams to support multiple versions simultaneously. For example, while developing a new version, a team can maintain and update an already released older version to ensure all versions receive timely support and fixes.
  • Disadvantages:
    • Relatively complex process: Due to the numerous branches, managing them can become burdensome for beginners or new teams.
    • Slower release cycles: Frequent use of short-lived branches makes Gitflow less meaningful, resulting in long branches becoming the norm. Slow release cycles may imply slower feedback.
    • Merge conflicts: Long-lived branches may cause significant differences among them, leading to merge conflicts when consolidating branches.

GitHub Flow

GitHub Flow revolves around an active development branch, usually main, which is directly deployed to production. Features and bug fixes are implemented through functionality branches. This methodology encourages feedback loops and asynchronous collaboration and is common in open-source projects.

It typically utilizes features provided by the GitHub platform, such as Pull Requests (requests to incorporate code into projects), Forks (cloning a project to a personal remote repository), and code reviews (discussion features for PRs) among others.

  • Advantages:
    • Intuitive and simple: Reduces complexity in branch management.
    • Fast reaction and feedback: A streamlined process suited for rapid development and frequent deployment, allowing for quicker feedback.
    • Very suitable for asynchronous work in small to medium-sized teams: The simple and direct process does not require waiting for prolonged central merges, making it ideal for team members to work asynchronously.
  • Disadvantages:
    • Higher risk of issues in production: Without proper testing and robust CI/CD, code reviews, etc., it is easier to introduce problems into production environments.
    • Better suited for single-version products: The simple structure makes it challenging to maintain and manage multiple release versions simultaneously.

GitLab Flow

GitLab Flow is a variant of GitHub Flow, with a similar basic process.

However, to address the issues of multi-version or multi-state management in GitHub Flow, some adjustments have been made. For instance, developers continuously push progress to the main branch, and when there is a need to prepare for release, they select progress to different purpose branches to resolve deployment and version management issues. For example, a staging branch is for test environments, and a production branch is for the formal environment.

  • Advantages:
    • All advantages of GitHub Flow
    • Capable of handling different versions and multiple environments.
  • Disadvantages:
    • A bit more complex than GitHub Flow.

Trunk Based Development

Trunk Based Development advocates for utilizing a single shared trunk branch, eliminating long-lived branches. When a release is needed, a release branch is built directly from the trunk. Depending on team size, there are two variations of this approach: smaller teams commit code directly to the trunk, while larger teams create short-lived feature branches, encouraging frequent integration of smaller function segments to ensure regular mergers.

The goal is to iterate as quickly as possible to resolve issues, reducing concerns around branch merging, test environments, and versions. This method heavily relies on team capabilities to maintain stability through automated testing.

  • Advantages:
    • Pursuing extremely rapid iteration and feedback.
  • Disadvantages:
    • Reliant on robust automated CI/CD and team capabilities to ensure stability.
    • Sometimes requires feature toggles🔗 mechanisms to prevent unfinished features from appearing in production.

Conclusion

I have identified several key factors that can help us choose the appropriate branching strategy: project type, team capabilities, and team structure.

  • Team capabilities: If the team possesses strong technical skills and automated testing, trunk based development might be a good choice, as it seeks extremely rapid iteration and feedback and relies on robust automated CI/CD to ensure stability. However, if the team lacks these capabilities, a more structured strategy like Gitflow may be more appropriate, as it provides clearer branch management and release cycles.

  • Team structure: In cases of large teams and cross-team collaboration, Gitflow may be more suitable as it clearly separates the development, testing, and release processes and supports maintaining multiple versions simultaneously. For small or adaptive teams, GitHub Flow or GitLab Flow may be more fitting, as the reduced process and quicker feedback accommodate rapid development.

  • Project type: For software requiring the maintenance of multiple versions concurrently, Gitflow may be a better fit as it supports simultaneous development and maintenance of multiple versions. For agile development or projects that require quick iterations, GitHub Flow or GitLab Flow might be more suitable as they offer faster feedback and flexible development processes.

Further Reading