Manage your repository visibility, rules, and settings
Repositories host application source code and other files, and are the core construct within which developers build software. They are used to access application security metrics, CI/CD workflows, and other day-to-day activities. Just as there are controls and permissions at the enterprise and organization levels, repositories offer controls to manage issue tracking, proposed changes, and code reviews.
For Philips, setting default repository visibility was core to their strategy for boosting collaboration and innersource.
In this guide, you will learn:
The visibility types available for repositories on GitHub for your user model
How to define conditions for merging pull requests using rulesets
How to use repository-level settings to provide fine-grained controls beyond organization- and enterprise-level restrictions
Repository visibility
There are three visibility types for repositories: public, internal, and private.
Public repositories are visible to the world and are primarily used for open source content.
Internal repositories are read-accessible to all full members of your enterprise account (not to outside collaborators).
Private repositories are only visible to individuals or teams who have been given explicit access, including through enterprise or organization base permissions.
Administrators can see all repositories within enterprises and organizations, regardless of their visibility, and administrators can change a repository’s visibility settings. Repository administrators, however, cannot change a repository’s visibility setting unless allowed by explicit policy.
Note: Changing repository visibility can have some downstream effects if you use forking or some other features. Review the impact of a repository visibility change before making a change.
Enterprises using Enterprise Managed Users (EMUs) prevent the creation of public repositories or changing the visibility of any existing repository to public.
Within our primary GitHub organization, we set the default repository visibility to internal to promote innersource by improving code discovery for re-use. Of course, there are reasons you might not want a repository to be fully visible to everyone, so we allow repositories to be set to private, but they have to first apply for an exception.
Rulesets and mergeability of pull requests
Rulesets are groups of rules that, among other things, define policies and set controls over who, when, how, and under what conditions a pull request may be merged. They can be defined per repository, set of repositories, or for entire organizations, and multiple rulesets can apply at one time and are evaluated using rule layering. When conditions for mergeability are set up, it’s not enough for a user to just have write access to a repository; they must also meet all of the mergeability conditions to have their pull request merge and become part of your codebase.
Some of the conditions that rulesets can check include:
Anyone with read access to a repository can see what rulesets are actively applied to that repository at any given time, so they can check the constraint status for a repository without being given additional access, and be aware of what constraints would apply if a change were to be requested.
Rules can be set to “evaluate” status on creation to check how they would apply before beginning to use them. The rule insights page provides a view of which user actions would be affected by evaluation mode rules.
If you’ve used GitHub for a while, you may also be familiar with branch protection rules. Branch protection rules are a legacy method of mergeability control. Existing branch protection rules can be combined with rulesets, but rulesets are more flexible and functional, and are the preferred method of mergeability control for GitHub going forward.
We created a bot using GitHub Actions to check all our repositories to make sure they have a YAML file designating the owner, permission levels, and other such characteristics. If it’s missing, the bot automatically creates an issue to ask the team to create it. That way, we can enable teams to employ innersource by default, rather than blocking them by default.
Repository settings
A few of the same settings we’ve seen at the enterprise and organization levels, including Actions policies, security feature enablement and policies, and forking settings, are available at the individual repository level. You can also enable and disable features like issues, GitHub Discussions, and legacy (“classic”) projects in each repository, which can be useful when you need to limit the use of certain repositories, such as during feature rollouts or when archiving content.
For any repository-level settings, these must be set to be more restrictive than any enterprise or organization policies or settings. For example, if your enterprise or organization policy is set to disallow any forking, you will not be able to allow forking per-repository. However, if the policy for your enterprise or organization permits use of any actions, you can set a per-repository policy to only permit use of a specified list of allowed actions in that repository.
Up next: Use teams, roles, and users to manage repository access
Now that we’ve set many of the base configurations at the enterprise, organization, and repository levels, it’s time to further subdivide access and recreate fine-grained corporate structures using teams and user roles.