Understanding Git Workflows: Git Flow, GitHub Flow, GitLab Flow, and Trunk‑Based Development

Modern software teams rely on standardized version‑control workflows to coordinate code changes, reduce merge conflicts, and ensure reliable releases. This article reviews the most common Git‑based workflows and explains why a team might choose one over another.

Git Flow introduces multiple long‑living branches (master, develop, feature, release, hotfix). Feature work is isolated on a feature/* branch, then merged back to develop and eventually to master for release. Its advantages are clear branch responsibilities and comprehensive coverage of development, release, and bug‑fix scenarios. The drawbacks are the overhead of many branch types and higher merge‑conflict risk.

GitHub Flow simplifies the model to only master and feature branches. When a feature is merged into master , the code is deployed immediately. This reduces branch complexity and enables rapid production deployments, but it lacks a dedicated release branch and a robust rollback mechanism, making it less suitable for projects requiring strict release control.

GitLab Flow builds on GitHub Flow by adding environment and version branches (pre‑production and production). Features are merged into develop first, then promoted to the appropriate release branch, allowing testing before production. It offers flexible release strategies but can become overly complex for teams that need a unified workflow.

Trunk‑Based Development (主干研发) encourages frequent commits directly to a designated trunk (often master or main ). Teams integrate small changes continuously, rely on automated testing to keep the trunk releasable, and create short‑lived release branches only when necessary. Benefits include reduced merge cost, higher code quality through continuous integration, and faster delivery. However, it demands strong collaboration, rigorous code review, and a mature CI pipeline.

The article also outlines scenarios where trunk‑based development fits front‑end work, such as small utility functions, rapid bug fixes, and feature‑first development, and compares it with feature‑branch approaches using illustrative diagrams.