The Flutter-Global GitHub organisation allows you collaborate with other divisions in Flutter.
The purpose of Flutter-Global is to allow you to collaborate across divisions within Flutter, often in an inner source model. Your division has it’s own divisional org, Flutter-Global allows you to share and work between divisions.
Flutter-Global supports both inner source and closed source cross divisional collaboration.
|All members of Flutter-Global have write access to contribute. Maintainers with admin access review all changes.
|All members of Flutter-Global have read access. A contributor team has write access. To contribute, a user must request to join this team. Maintainers with admin access review all changes.
|A reader team has read access. A contributor team has write access. To contribute or view the repo, a user must request to join one of these teams. A team of maintainers have admin access.
|Only repository maintainers with admin access can view or contribute.
Recommended branching model patterns explained in under 7 minutes!
We recommend you choose one of:
- Reviewed Source : Simple pull request based workflow where expert code maintainers review all changes before release.
- Audited Source : Ensures history is immutable for audit, but changes don’t require approval before release.
- Multiple Team Source : A derivative of GitFlow to provide each team with their own develop branch.
Flutter-Global has thousands of repositories and GitHub doesn’t have any native way to group or link them (e.g. like ‘projects’ in GitLab or Atlassian BitBucket). We group related repositories together into capabilities using Codebase Governor.
- A capability is a group of related repositories that does something meaningful (e.g. a product feature).
- Each GitHub repository is part of a single capability.
- A capability has an owner and a team of expert maintainers.
- Not all repositories in Flutter-Global are part of a capability, but it’s a requirement to use Codebase Governor.
An inner source application typically have a single shared codebase and several divisional deployments. It’s not enough just to share the code: you need to share and collaborate on your CI pipeline. GitHub Action workflows are the best way to do this.
We document standard patterns to cover steps (1)-(5). Steps after that are division specific and dependent on divisional conventions and tools.