Branching Strategy

How to choose and enforce a suitable branching strategy for your repository.

This public content is an excerpt from Flutter staff GitHub docs. It is published as a reference to show how GitHub is used for inner source at Flutter.

As a repository maintainer you are responsible for choosing and enforcing a branching strategy for your repository.

Recommended branching model patterns explained in under 7 minutes!

We recommend you choose one of:

  1. Reviewed Source : Simple pull request based workflow where expert code maintainers review all changes before release.
  2. Audited Source : Ensures history is immutable for audit, but changes don’t require approval before release.
  3. Multiple Team Source : A derivative of GitFlow to provide each team with their own develop branch.

Your choice of branching strategy considers but is separate to your choice of access model for your repository. If unsure – choose Reviewed Source and evolve it forward.

Branch Protection

Branch protection is a feature provided by GitHub to apply rules to repository branches. For example to limit those able to push commits to the branch, or enforcing approval rules before merge.

You use branch protection in your repository to enforce your choice of branching strategy for your contributors. There are 3 ways to configure branch protection rules:

  1. Manually apply per-repository in the GitHub repository settings.
  2. RECOMMENDED: Configure using the Codebase Governor.
  3. Automate it yourself via the GitHub API.

Simple Codebase Governor setup instructions for each recommended branching strategy:

Using the Codebase Governor branch-protections key enables you:

Further Reading

Branching strategy is a complex topic. Useful further reading is:

Examples

Read more detailed examples and reasoning on the branching examples page.