Internal repositories are now generally available for GitHub Enterprise
Now out of beta, the internal repository visibility allows an enterprise-owned repository to be read by any member of any organization that belongs to an enterprise account.
![](https://github.blog/wp-content/uploads/2019/03/company-twitter.png?resize=1201%2C630)
After the public beta announcement at GitHub Satellite, we’ve continued adding to the internal repository visibility and it’s now generally available as of October 28. We’d like to thank all of the beta participants for their engagement and feedback during this beta period. Your input played a critical role in creating this feature and the direction that brought the product to where it is today.
The role of customer feedback
We received over 100 unique enterprise customer requests and countless more individual developer reports, all enthusiastic about bringing the innersource methodology to their businesses. The internal repository visibility allows an enterprise-owned repository to be read by any member of any organization that belongs to an enterprise account.
We wanted our customers to have this feature quickly, but we knew we had some work to do after launch. Some of the feedback we received during the beta was expected, like requests for API support and more specific search capabilities. What we didn’t expect was that many users, including some internal to GitHub, thought that these repositories were internal to a specific GitHub organization. Here’s why we think that happened:
- Limited in-product guidance from GitHub at launch
- Strong association to organizations being the top-level owner of repositories
- Enterprise accounts were brand new and many users didn’t know how they became an “enterprise member”
We made a few precise changes to internal repositories to help our users.
What we changed during the beta
- Updated repository creation dialog and new enterprise policy settings [details]
- New documentation describing the role of “enterprise member” [details]
- New search filters that isolate internal repositories
- Updated organization and repository API endpoints that include “internal” types
- Forking policy was updated to reflect the same behavior that would apply to a private repository [details]
The first and second changes were almost entirely responses to customer feedback, which we’ll cover in the following sections.
Repository creation design
At launch, we needed to provide an interface that allows you to create an internal repository and understand the core differences from internal, public, or private options. Let’s take a look at the interface before and after we made a few updates.
In the new repository dialog at launch, “GitHub” is both the name of an enterprise account and organization. We’re telling the user that all members of the GitHub account can see this repository. Since we can’t see what kind of entity “GitHub” is, it wasn’t clear who could see the repository. This led users to believe that the visibility was organization-wide instead of across the enterprise account. For clarity, we added the enterprise account’s avatar to the dialog and changed the text to state that “enterprise members” of the enterprise account will be able to see this organization-owned repository. This removes ambiguity between the organization and enterprise account names.
Who is an enterprise member?
During the beta, one of the most interesting things we learned is that the members of organizations belonging to an enterprise account didn’t really notice that they were members of an enterprise account rather than a collection of GitHub organizations. While this was not disruptive to the user’s regular behavior, it was a primary cause of confusion around who could (or should) be able to see an internal repository. To address this, a distinct role description for enterprise members was added that we link directly in the new repository creation dialog.
Thank you for your feedback
Without valuable input from our users, we wouldn’t have been able to create this feature or improve the user experience. We can’t express our thanks enough and hope you’ll continue collaborating with us. Ready to give us more feedback? Share your comments with us. Be sure to select “Teams, organizations, or Enterprise accounts” where our product team will be watching for items related to internal repositories.
Upcoming changes to GitHub Enterprise Server
With the upcoming release of GHES 2.20, we’re adding the internal repository visibility to our on-premises offering and creating a uniform experience for both Cloud and Server platforms. Stay tuned for more updates as we continually improve your experience.
Learn more about internal repositories
Tags:
Written by
Related posts
![](https://github.blog/wp-content/uploads/2023/10/Collaboration-DarkMode-2.png?resize=400%2C212)
2024 is the biggest global election year in history. What’s at stake for developers?
GitHub is considering what is at stake for our users and platform, how we can take responsible action to support free and fair elections, and how developers contribute to resilient democratic processes.
![](https://github.blog/wp-content/uploads/2023/10/AI-DarkMode-2.png?resize=400%2C212)
GitHub named a Leader in the Gartner first-ever Magic Quadrant for AI Code Assistants
This year, as part of its annual Magic Quadrant series, Gartner published a first-of-its-kind report analyzing the state of play in the AI Code Assistants market–and named GitHub a Leader.
![AI in software development 2024 survey results with colorful graphics and percentages.](https://github.blog/wp-content/uploads/2024/08/ai-survey-header.png?resize=400%2C212)
Survey: The AI wave continues to grow on software development teams
We surveyed 2,000 people on software development teams at enterprises in the U.S., Brazil, India, and Germany about the use, experience, and expectations around generative AI tools in software development.