Choosing the Right Git Workflow for Monorepo: Feature Branch vs. Trunk‑Based Development

Background – No single Git workflow fits every project; the choice depends on codebase size, team size, and use cases. The article first introduces a feature‑branch workflow suitable for small monorepos, then a trunk‑based workflow for medium‑to‑large monorepos, and finally offers selection criteria.

Prerequisite Knowledge – Common Git flows such as Git Flow, GitLab Flow, and GitHub Flow belong to the feature‑branch family, which emphasizes feature‑driven development where each feature or hot‑fix lives on its own branch.

Applicable Scenarios – In a monorepo, as the codebase and team grow, long‑lived feature branches increase merge conflicts and bugs. Trunk‑based development encourages short‑lived branches and frequent merges, reducing conflicts and keeping the production version stable.

Feature Branch Development

Definition: All new features are developed on dedicated branches, keeping the main branch clean for CI. This isolates work, allows multiple developers to work concurrently, and prevents broken code from reaching the main line.

Typical release process:

Create a feature branch from master .

Develop on the feature branch.

Build and hand over to QA.

If issues arise, create a fix MR based on the feature branch, merge, rebuild, and retest.

After QA approval, merge the feature branch into master and delete it.

Advantages: enables parallel development, keeps master stable, and reduces mental overhead because only simple operations are required.

Trunk‑Based Development

Definition: Developers make small, frequent commits directly to the main trunk (usually master ), often using short‑lived branches for releases.

Release modes:

From a release branch (RC)

Create an RC branch from master , build, and send to QA.

If bugs are found, create a fix MR on master , merge, cherry‑pick the fix onto the RC, rebuild, and retest.

After QA approval, deploy the RC and delete it.

From the trunk directly

Fully automated flow for high‑frequency deployments with comprehensive automated tests.

Advantages: supports continuous integration (CI), continuous code review (CR), continuous delivery (CD), linear commit history, and scales well for large monorepos with many collaborators.

Two Essential Preconditions

Continuous integration and testing – developers must know the impact of each merge.

Feature flags – allow incomplete features to be merged safely without exposing them to users.

Reference

A tidy, linear Git history: https://www.bitsnbites.eu/a-tidy-linear-git-history/