Public preview feedback: Enterprise repository properties, policies and rulesets

[patrick-knight]

Thanks for exploring enterprise properties, policies and rulesets! We are excited to introduce a host of new features to help you better govern your enterprise as part of this public preview. If you’re here to share feedback on the merge method rule you’re in the right spot!

Enterprise custom repository properties

Create properties at the enterprise level that become available across all organizations. Providing you a way to share properties across all orgs without having to synchronize properties and deal with duplication, so you have a central place to control all enterprise-wide properties. The creation experience is nearly the same as repo properties at the org, where you create a property with a name and a type, but enterprise properties do not have the set value experience which is done per organization.

To learn more about enterprise custom properties, head over to the docs.

Planned enhancements for general availability

• Enterprise owners will be able to filter and search for properties across all organizations.
• Enterprise owners will be able to promote an organization owned custom properties to the enterprise.

Known limitations

• There is a shared namespace across repository properties so properties created by an organization or enterprise must be uniquely named.
• Enterprise properties are not available on the enterprise security overview.

Enterprise repository policies

An easy way across your enterprise to say certain types of repositories, based on custom properties, can’t be transferred, or deleted or have its visibility changed in a granular way. Policies can also apply to organizations and enterprise managed user repositories.

To learn more about enterprise repository policies, head over to the docs.

Planned enhancements for general availability

• Policies to manage forking and archiving of repositories.

Known limitations

• Policies for enterprise managed users will apply to all of those repositories, with no additional granularity.

Enterprise code rulesets

Create branch, tag and push rules at the enterprise, that include rule insights and push rule delegated bypasses.

Planned enhancements for general availability

• Support for the “require workflows to pass before merging” rule

Known issues

• Bypass list is limited to built-in roles and deploy keys
• The following branch rules are not available at the enterprise level:
  • Require deployments to succeed
  • Require merge queue
  • Require status checks to pass
  • Require workflows to pass before merging

Feedback

We want to hear from you! Add your comments, questions, likes and dislikes below. 🔽

[chrisreddington]

Looking for a quick overview and hands-on demo? Check out our video on GitHub's YouTube Channel

[Belgarus]

Okay, thanks :)

[IAmHughes]

Hey @patrick-knight

Thanks for the discussion around this. We find this to be a very exciting feature to track; however, the "200 values per property" limit is quite limiting for our use case. We want to identify repositories by the business service they support. We have over 2,000 business services and 100,000 repositories. If the property was business-service and the value was the specific service itself, we'd hit our 200 limit and require 10 properties be labeled incrementally such as, business-service1, business-service2, etc. to allow for the total number of values, resulting in a poor UX.

Is this 200 limit in place as a rough rate limit attempt while in preview or due to actual performance issues? I understand for use cases such as environment, for example, there's no need for a long list; but our use case would require multiple thousand values. A potential workaround we were considering before custom properties was to look at repository labels instead; however, these are less ideal.

[patrick-knight]

The limit is the same as what exists for organization owned properties. This was an implementation choice based on UX constraints as well as platform scalability, but we continue to evaluate the data and feedback around the existing limits.

Out of curiosity what's the current location that business-service is tracked today outside GitHub?

[IAmHughes]

The limit is the same as what exists for organization owned properties. This was an implementation choice based on UX constraints as well as platform scalability, but we continue to evaluate the data and feedback around the existing limits.

I understand the limit is the same on an org level and enterprise level, but we'd still want to see the limit increased.

I know GitHub has a lot of opportunity when it comes to UX in terms of pagination, but it can't be any worse than other areas of the application with large pagination and no filters 😛 - Understood though and I appreciate you want the UX to be a good experience as well.

For scalability, I can understand that being a potential limiting factor as well, though I hope this can be increased/optimized by y'all for the use case I described. I can't imagine looking up a key with 1000 possible values is a very large compute lift over 200 possible values, but I don't know the full data structure y'all went with of course and won't pretend to 😄

Out of curiosity what's the current location that business-service is tracked today outside GitHub?

It's managed in a few places right now (we're actually trying to centralize this data as well for a single source of truth that could then be mapped to GitHub) including an internal tool, a system built on the open source backstage project, and some in AzureAD/EntraID as well, though again it's a bit of a work in progress on standardization we're doing as well.

Another thought on justifying the additional limit would be that the billing team has found a way to not limit (or at least I don't see one listed in the Docs for cost-centers. Enterprises may have hundreds of cost centers, so I'm curious what their limit is (if one exists and isn't documented) or maybe how they're handling the UX of more than 200? Just a thought on another approach to it 👍

[patrick-knight]

Properties are available via a few vectors like the organization list view, security overview and targeting in rulesets. So we have to ensure they scale performantly across multiple surface areas. The performant piece being keys as you can set security and policy based on properties with rulesets.

That all said we're continuing to invest in this space and your feedback around how you'd like to use properties and it's limitation are helpful as we make future decisions.

[Timmmy-nlb]

Hello,
I am trying to set up a rule under Enterprise / policy / code / Code rulesets:
All repos with a certain name in all organizations should be forced to a pull request.

But unfortunately it is not possible to specify the names of the affected repos.
At this point there is only the option "dynamic list by property: fork, language, visibility" - not the use of "dynamic list by name" as at org level
Why?

[patrick-knight]

It is not supported today as part of the preview as we had a few concerns around ensuring how to handle or message potential repo name collisions across orgs to drive clarity if policy might be applied in unexpected ways, there a few technical constraints that drove that decision as well.

[Timmmy-nlb]

But I hope exactly this method will be supported in the future? That would be the only use that would apply to us at this point.

[kailashsam]

@patrick-knight, we really would love to use this feature but without the ability to exclude/include repos by their names, we wont be able to make use of it. You mention that one concern was about repo name collisions across orgs. Would it be possible to allow specifying the repo name with org name, so that the org name will be the differentiator? That way, even if the repo names are same in 2 orgs, it won't be causing any issues?

[nickej]

I can not see these features in the API yet I might be missing something or are they not there? We would love to use the enterprise policy features but prefer setting up our enterprise and organizations using code.

[IAmHughes]

It exists, remember some things in API docs need to have the dropdown in the top left to your version (including GitHub Enterprise Cloud)

• Enterprise custom properties
• Enterprise repo rulesets
• Organization custom properties
• Organization rulesets
• Repo custom properties
• Repo rulesets

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[ilan-go]

UX feedback around “Allow list” behavior for repository naming rules

We’re using the new Restrict names repository policy and had some feedback on the current allow‑list UX.

Today, the allow list has two options - “always” and “exempt” - which effectively creates a binary experience:

• If you’re not in the allow list, repository creation is fully blocked when the name doesn’t match the convention.
• If you are in the bypass list, the naming rule is ignored entirely, with no indication that the name is outside the convention.

This makes it hard to balance governance with awareness. In practice, bypass users may unintentionally create non‑conforming names without realizing it.

A potentially better UX could be:

• Showing a warning when a bypassed user creates a repo that doesn’t match the naming convention, or
• Allowing users to follow the rule by default but explicitly “bypass” it via a confirmation action (similar to other rule bypass flows).

This would preserve flexibility for admins and power users, while still reinforcing naming standards and intent.
Since this is a preview feature, sharing in case it’s helpful as the policy and allow‑list semantics evolve.

[paulafernandesnu]

Hello! I've created a repository policy in my organization to restrict visibility (to internal and private). The policy is enabled, but a user was able to transfer a public repository from his organization to my organization (as public repository). Isn't something that should be blocked via this ruleset?