Governing how people use repositories in your enterprise

To govern key events in the lifecycle of your repositories, such as who can create or delete repositories, you can create a repository policy. A repository policy is a collection of restrictions that gives you flexible control over which users are affected and which repositories are targeted.

In a repository policy, you can restrict:

• Which visibilities are permitted for new repositories and visibility changes.
• Who can create repositories.
• Who can delete repositories.
• Who can transfer repositories out of an organization.
• How people can name repositories.

Examples

You can use a repository policy to do things like:

• Ensure all new repositories use a certain naming convention, such as kebab-case.
• Prevent repository deletions except by organization admins.
• Allow public repositories to be created only in the "open source" organization in your enterprise.
• Prevent public repositories from being changed to private to avoid potential loss of metadata.

How will I target repositories?

First, you'll target organizations in your enterprise. You can select all organizations, choose from a list, or create a dynamic rule using fnmatch syntax. If you use Enterprise Managed Users, you can also choose to target all repositories owned by users in your enterprise.

Then, you'll target repositories in the selected organizations. We recommend using repository policies alongside custom repository properties. By adding custom properties to repositories, you will be able to flexibly target those repositories in a policy.

For example, you can add a property to mark repositories that contain production data or other sensitive information, then prevent anyone from making those repositories public.

To create and set custom properties, see Managing custom properties for repositories in your organization.

Interaction with other policies

Some of the available restrictions are duplicates of policies you may have set on the "Member privileges" page in your organization or enterprise settings.

Creating a repository policy does not override your existing "member privilege" policies. Instead, the policies are additive, so that the most restrictive version of a policy applies. This applies both to member privilege policies and to other repository policies that people have created at the enterprise or organization level.

Compared to member privilege policies, repository policies have several advantages:

• They offer more flexible targeting of organizations and repositories.
• They allow you to give certain actors the option to bypass the policies.
• They're visible to organization owners, so there is more transparency around what is permitted.
• They allow you to target repositories owned by Enterprise Managed Users.

Creating a repository policy

1. In the top-right corner of GitHub, click your profile photo.
2. Depending on your environment, click Your enterprise, or click Your enterprises then click the enterprise you want to view.
3. On the left side of the page, in the enterprise account sidebar, click Policies.
4. Under "Policies", click Repository.
5. Click New policy.
6. Configure your new policy, then click Create. For help, consult the following subsections.

Policy name

Use something descriptive to communicate the purpose of the policy. Organization owners can view the policy, so good names help add clarity. For example: Prevent public repos on production.

Enforcement status

If you don't want the policy to be enforced when it's created, set to "Disabled". Otherwise, set to "Active".

Allow list

Choose which roles and teams can bypass the restrictions in this policy.

Targets

Choose which organizations and repositories the policy applies to.

Target organizations

Select all organizations, choose a selection of existing organizations, or set a dynamic list by name. If you use Enterprise Managed Users, you can also choose to target all repositories owned by users in your enterprise.

If you set a dynamic list, you'll add one or more naming patterns using fnmatch syntax. For example, the string *open-source would match any organization with a name that ends with open-source. For syntax details, see Creating rulesets for a repository.

Target repositories

Choose which repositories (current or future) to target in the selected organizations. You can select all repositories or set a dynamic list by custom property.

Policies

Choose which restrictions are included. When the policy is active, the restrictions apply across all targeted repositories, but can be bypassed by users or teams on the allow list.

If you choose the "Restrict names" policy, you must use regular expression syntax to set a pattern that repository names must or must not match. For example, a pattern to enforce kebab-case naming would look like ^([a-z][a-z0-9]*)(-[a-z0-9]+)*$.

• Patterns support RE2 syntax. See Google's syntax guide.
• To validate your expressions, click Test pattern, then enter a pattern and test value.

Further reading

To set additional policies for repository management, see Enforcing repository management policies in your enterprise.