Multiple Team Source

A source code setup for repos with several teams making changes in parallel. Uses a derivative of GitFlow to provide flexible releases with each team managing their own develop branch.

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.

Multiple Team Source is best when several busy teams are working on the same codebase or you have a long release process. This branching model is a derivative of GitFlow to provide each team with their own develop branch. Cross-team alignment occurs during regular releases. You can use semver git tags to label releases and trigger alpha, beta and production builds. To support multiple deployments, you can patch previous versions in their dedicated support branches.

Recommended branching model patterns explained in under 7 minutes!

Quick Start

Create a team develop branch, e.g. for a team named ppb:

git checkout main
git checkout -b ppb/develop
git push -u origin ppb/develop

Start using the branching model through git flutter shortcuts. Install this helper with:

curl -o- https://innersource.flutter.com/git-flutter/install.sh | bash

View repository status:

git flutter status

Ready to try it?

The sandbox-mt repository is a sandbox area for you to use.

sandbox-mt on GitHub

Create a feature:

git flutter feature "my feature name"

To push your work and open a PR:

git flutter push -w

Create a release once the feature is merged to develop:

git flutter release "name or version"

Tag alpha (develop branch), beta (release branch) or production build (main branch):

git flutter tag

Quick Setup

Create a team develop branch for each team, e.g. to create a ppb team branch:

git checkout main
git checkout -b ppb/develop
git push -u origin ppb/develop

If you are configuring a completely new repository use the full setup guide. However for most you just need to update your branch protections in your Codebase Governor config file:

branch-protections:
  - patterns:
      - "main"
      - "master"
      - "support/*"
    parameters:
      required-reviews-count: 2
      requires-codeowner-reviews: true
      requires-status-checks: true
  - patterns:
      - "*/develop"
      - "*/release/*"
    parameters:
      required-reviews-count: 1
      requires-codeowner-reviews: true
      requires-status-checks: true
      allow-admin-bypass: true
      allow-stale-reviews: true
      allow-stale-branch-merge: true
      allows-deletions: true

If you are using tags to trigger builds use the GitHub web interface to add a tag protection rule for the v* pattern (Settings > Tags > New Rule).

Learn More

Setup
Next →