Governing how people use repositories in your organization

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?

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.

As an alternative to custom properties, you can choose from a list of repositories or use fnmatch syntax to target repositories with certain naming patterns.

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.

Creating a repository policy

1. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.
2. Next to the organization, click Settings.
3. On the left side of the page, in the 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. 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 repositories in the organization the policy applies to. You can select all repositories, choose a selection of existing repositories, or create a dynamic rule by name or custom property for current and future repositories.

If you set a dynamic list by name, you'll add one or more naming patterns using fnmatch syntax.

• For example, the string *open-source would match any repository with a name that ends with open-source. For syntax details, see Creating rulesets for a repository.
• Optionally, you can prevent anyone outside the allow list from renaming the selected repositories. Alternatively, you can control the format of names in the "Policies" section.

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.