Git Workflows

Git workflows define how teams collaborate using version control. The right workflow depends on team size, release cadence, and deployment requirements. This article compares the major workflows—trunk-based development, GitHub Flow, GitFlow, and monorepo strategies—with guidance for choosing the right approach.

Trunk-Based Development

Trunk-based development is the simplest workflow. Developers commit directly to the main branch (trunk) or create short-lived feature branches that merge within hours, not days. The main branch is always in a deployable state.

Trunk-based development works well with CI/CD and feature flags. Incomplete features are hidden behind feature flags, allowing frequent merges without affecting users. The workflow minimizes merge conflicts, simplifies history, and enables continuous deployment.

Trunk-based development is best suited for teams practicing continuous delivery. It requires discipline: commits must be small, tests must pass before merge, and feature flags must be managed carefully. For teams deploying multiple times per day, trunk-based development is the natural choice.

GitHub Flow

GitHub Flow is a branch-based workflow centered on pull requests. Developers create feature branches from main, make changes, open a pull request, and merge after review. The main branch is always deployable.

GitHub Flow adds code review to trunk-based development's simplicity. Every change is reviewed before merge. CI runs on the branch before merge. After review and passing CI, the branch merges to main and deploys.

GitHub Flow is appropriate for most teams. It adds necessary review overhead without the complexity of long-lived branches. The workflow is well-supported by GitHub's tools and integrates naturally with CI/CD pipelines. Most open-source projects and many companies use GitHub Flow.

GitFlow

GitFlow uses multiple long-lived branches: `develop` for integration, `main` for production releases, `feature/*` for features, `release/*` for release preparation, and `hotfix/*` for urgent fixes. This structure supports scheduled releases and parallel development of multiple features.

GitFlow is appropriate for projects with scheduled releases, where the main branch represents the current production release, and development continues on the develop branch between releases. Release branches allow last-minute bug fixes without blocking features intended for the next release.

GitFlow's complexity is its main downside. The multiple branch types and merge patterns create a complex graph. The workflow assumes release-based development, which conflicts with continuous deployment. For teams deploying continuously, GitFlow adds unnecessary overhead.

Monorepo Strategies

A monorepo stores multiple projects in a single repository. Monorepo strategies use specialized tools and conventions to manage the complexity of shared code, independent versioning, and targeted builds.

Monorepos require build tools that understand project dependencies. Nx, Turborepo, Bazel, and Pants analyze the dependency graph to build and test only affected projects. A change to a shared library triggers tests for all dependent projects, but a change to one application does not touch others.

Monorepo workflows typically use trunk-based development within each project area. Teams may use CODEOWNERS files to define review requirements for different parts of the repository. Monorepos work best with strong tooling investment—without it, the repository becomes unwieldy.

Choosing a Workflow

Team size is the primary factor in workflow selection. Small teams (1-5 people) can use trunk-based development with minimal ceremony. Medium teams (5-20) benefit from GitHub Flow's review process. Large teams (20+) may need GitFlow's release management or a monorepo's project isolation.

Release frequency is another factor. Daily or continuous deployments favor trunk-based development or GitHub Flow. Scheduled releases favor GitFlow. Monorepo workflows work with any cadence but require tooling investment.

The best workflow is the one your team follows consistently. A simple workflow that everyone follows is better than a sophisticated workflow that creates confusion. Start with GitHub Flow and adjust as the team grows and requirements evolve.

Best Practices

Regardless of workflow, certain practices apply. Write meaningful commit messages. Keep commits focused on single changes. Rebase feature branches on main before merging. Keep the main branch green (always passing tests). Delete branches after merging. Use signed commits for security.

Git workflows are tools, not rules. Adjust the workflow to fit your team's needs. The goal is efficient collaboration, not workflow purity. The right workflow is the one that enables your team to deliver software reliably and efficiently.