| English | 中文 |
No Git workflow is universally correct.
Every workflow is a trade-off among speed, safety, release frequency, team size, and product complexity.
| Team / Product | Recommended Workflow | Rationale |
|---|---|---|
| Small team web products | GitHub Flow | Short branches, fast merges, frequent releases |
| High-frequency backend services | Trunk-Based Development | Stable trunk, fast CI feedback, clean rollbacks |
| Medium-to-large business teams | Feature Branch + Protected Main | Balances parallel development with main branch stability |
| Open-source projects | Fork + Pull Request | Reduces write-access risk from external contributors |
| Multi-version delivery products | Release Branch | Must maintain multiple live versions simultaneously |
| Multi-environment SaaS / internal enterprise platforms | GitLab Flow | Merge and deploy frequencies differ; needs production / stable branches |
| Mobile / desktop clients | Release Branch + Hotfix | Long release cycles, fragmented live versions |
| Legacy system maintenance | Conservative Branch Strategy | Infrequent changes, high risk, stability first |
main -> feature branch -> pull request -> review -> CI -> merge -> deploy
main is always deployableshort-lived branch -> main -> CI -> deploy
GitHub Flow is a lightweight process built around GitHub’s platform: short branches, PRs, reviews, and merging into the default branch.
Trunk-Based Development is an organizational principle: branch lifetimes are measured in hours, the team integrates continuously against the trunk, and the trunk stays deployable at all times.
Add required CI, CODEOWNERS, Rulesets, Merge Queue, feature flags, and release-from-main to a GitHub Flow setup, and you arrive at the enterprise implementation of trunk-based development.
This is the practical default for most medium-to-large business teams.
main or masterGitHub branch protection rules can enforce reviews, status checks, linear history, merge queues, and more. See protected branches in the GitHub docs.
Gitflow works well for products with a defined release cadence: desktop clients, SDKs, and enterprise delivery products.
Gitflow’s branch model has historical value, but applying it across every team adds complexity without proportional benefit.
GitLab Flow fits teams where merge frequency and release frequency do not align.
It keeps the lightweight collaboration of feature branches and merge requests, and adds production and stable/* branches to represent live state and stable version lines.
See GitLab Flow for details.
fork -> branch -> commit -> pull request -> maintainer review -> merge
main -> release/1.8 -> bugfix -> tag -> hotfix -> back merge
Microsoft Release Flow offers a proven combination of both approaches: the trunk carries day-to-day development, release branches are cut per sprint or release window, and fixes flow back to the trunk. See Microsoft Release Flow for details.
Problem: Merge risk compounds over time, and trunk feedback stops being useful.
Recommendation: Break work into smaller tasks, merge early, and hide unfinished work behind feature flags.
Problem: The main branch can break at any time, and accountability is unclear.
Recommendation: Enable branch protection, require PR reviews, and make CI mandatory.
Problem: Reviews become a rubber stamp.
Recommendation: One PR, one problem. Keep refactoring and behavioral changes in separate PRs.
Problem: The team’s actual constraints get ignored.
Recommendation: Match the workflow to your release cadence, team size, and risk tolerance.
| Practice | Key Takeaways |
|---|---|
| Alibaba AoneFlow | Release branches define the release scope, enabling flexible feature inclusion and removal |
| Tencent Gitflow Branching Practice | Well-suited for fixed-version release cycles with dedicated release testing and hotfix backporting |
| ByteDance Git Workflow | Unifies branches, permissions, reviews, CI, and releases into a single engineering platform |
| Google Trunk-Based Development | Short branches, fast CI, and small commits power collaboration at massive scale |
| Microsoft Release Flow | Trunk-based development paired with release branches, designed for teams with fixed release windows |
| Meta Sapling | Stacked commits express large features as a chain of small, reviewable changes |
Before borrowing from any of these, assess your own release frequency, team size, testing maturity, and ability to roll back in production.
Moving from an old process to a new one works best as a sequence of small, deliberate steps — not a big-bang switchover.
Recommended sequence: