Git Workflow Strategies and Company Practices at Bytedance

Industry Git Workflow Overview

Git Flow

Git Flow offers many advantages: dedicated branches for different development scenarios, every commit on master is deployable, and strict process adherence reduces major incidents. Its drawbacks include excessive complexity, violation of short‑lived branch principles, a noisy master history, and poor fit for continuous deployment or monorepos.

GitHub Flow

GitHub Flow is a lightweight, branch‑based workflow that emphasizes code review (CR) but does not address deployment, environment, release, or integration concerns.

GitLab Flow

GitLab Flow builds on GitHub Flow by incorporating environment deployment and project‑management considerations. It can be organized by environment or by release plan.

Trunk‑based Flow

Similar to the release‑plan variant of GitLab Flow, a single trunk branch receives all developer commits, supporting CI/CD. Teams may optionally use pull‑requests, keep feature branches short‑lived, and merge to release‑* branches for production releases.

Aone Flow

Aone Flow maps each release branch to a specific environment (e.g., release/test, release/prod) and can extend to multiple environments per branch, ensuring consistent testing across stages. It suits large teams with complex repositories but can become unwieldy for frequent release cycles.

Company Practice

Multi‑Environment Deployment at Bytedance

Server Side

Bytedance runs services on a private cloud Compute Engine (CE) with artifacts managed by an Artifact Repository (AR). Traffic is routed to different environments using headers such as -H 'x-env-tag:{env}', supporting development, QA, pre‑release, low‑traffic, and full‑release stages.

Frontend Side

Frontend resources are produced per AR version; URLs map N:1 to ARs. Separate domains can be generated for test and preview environments, and the same header technique is used for environment routing.

Team‑Specific Git Workflows

Based on the front‑ and back‑end deployment realities, three R&D processes are defined: feature testing, QA testing, and production release, each with corresponding Git workflows.

Bytedance currently adopts three workflow patterns:

Single‑trunk (fast iteration)

Double‑trunk (periodic releases)

Triple‑trunk (large‑scale app releases)

Single‑Trunk Practice

Frontend Micro‑service Platform

For a mature frontend micro‑service, developers work on short‑lived feature/fix branches, open a Merge Request, pass CR, and test on a baseline environment. No dedicated functional‑test environment is used, which can be risky for larger changes.

Double‑Trunk Practice

Private Cloud Platform

Initially each deployment environment had its own branch, leading to fragmented testing. After simplification, a standard Trunk‑based Flow now satisfies online, sandbox, and BOE environments.

Business Middleware

Key challenges include feature conflicts during integration, master updates not being synchronized before release, and the need for short‑lived release branches that act as both testing and release streams.

Triple‑Trunk Practice

Hundred‑Million‑User App

App releases are the most complex scenario, requiring strict release cadence, feature toggles, and hot‑update mechanisms to avoid user churn.

Conclusion

The article presents a multi‑angle analysis of Git workflow usage, emphasizing that a well‑designed workflow ensures reliable testing and safe releases. Combining environment management, traffic routing, connectivity testing, and CI/CD creates a full‑link guarantee for rapid iteration and secure deployment.

References

Trunk‑based Development vs. Git Flow – https://www.toptal.com/software/trunk-based-development-git-flow

Please stop recommending Git Flow! – https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/

Understanding the GitHub flow – https://guides.github.com/introduction/flow/index.html

Introduction to GitLab Flow – https://docs.gitlab.com/ee/topics/gitlab_flow.html

https://cn.trunkbaseddevelopment.com

在阿里，我们如何管理代码分支？ – https://developer.aliyun.com/article/573549

Google's code management – http://www.ruanyifeng.com/blog/2016/07/google-monolithic-source-repository.html