About repositories
You can own repositories individually, or you can share ownership of repositories with other people in an organization.
You can restrict who has access to a repository by choosing the repository's visibility. For more information, see "About repository visibility."
For user-owned repositories, you can give other people collaborator access so that they can collaborate on your project. If a repository is owned by an organization, you can give organization members access permissions to collaborate on your repository. For more information, see "Permission levels for a personal account repository" and "Repository roles for an organization."
Each person and organization can own unlimited repositories and invite an unlimited number of collaborators to all repositories.
You can use repositories to manage your work and collaborate with others.
- You can use issues to collect user feedback, report software bugs, and organize tasks you'd like to accomplish. For more information, see "About issues."
- You can use pull requests to propose changes to a repository. For more information, see "About pull requests."
- You can use project boards to organize and prioritize your issues and pull requests. For more information, see "About project boards."
To learn how to use repositories most effectively, see "Best practices for repositories."
About repository visibility
You can restrict who has access to a repository by choosing a repository's visibility: public, internal, or private.
When you create a repository, you can choose to make the repository public or private. If you're creating the repository in an organization, you can also choose to make the repository internal.
- If your GitHub Enterprise Server instance is not in private mode or behind a firewall, public repositories are accessible to everyone on the internet. Otherwise, public repositories are available to everyone using your GitHub Enterprise Server instance, including outside collaborators.
- Private repositories are only accessible to you, people you explicitly share access with, and, for organization repositories, certain organization members.
- Internal repositories are accessible to all enterprise members. For more information, see "About internal repositories."
Organization owners always have access to every repository created in an organization. For more information, see "Repository roles for an organization."
People with admin permissions for a repository can change an existing repository's visibility. For more information, see "Setting repository visibility."
About internal repositories
You can use internal repositories to practice "innersource" within your enterprise. Members of your enterprise can collaborate using open source methodologies without sharing proprietary information publicly, even with private mode disabled. For more information on innersource, see GitHub's whitepaper "An introduction to innersource."
All enterprise members have read permissions to the internal repository, but internal repositories are not visible to people who are not members of any organization, including outside collaborators on organization repositories. For more information, see "Roles in an enterprise" and "Repository roles for an organization."
Note: A user must be part of an organization to be an enterprise member and have access to internal repositories. If a user on your GitHub Enterprise Server instance is not a member of any organization, that user will not have access to internal repositories.
Members of the enterprise can fork any internal repository owned by an organization in the enterprise. The forked repository will belong to the member's personal account, and the visibility of the fork will be private. If a user is removed from all organizations owned by the enterprise, that user's forks of internal repositories are removed automatically.
Limits for viewing content and diffs in a repository
Certain types of resources can be quite large, requiring excessive processing on GitHub Enterprise Server. Because of this, limits are set to ensure requests complete in a reasonable amount of time.
Most of the limits below affect both GitHub Enterprise Server and the API.
Text limits
Text files over 512 KB are always displayed as plain text. Code is not syntax highlighted, and prose files are not converted to HTML (such as Markdown, AsciiDoc, etc.).
Text files over 5 MB are only available through their raw URLs, which are served through HOSTNAME/user/repo/raw; for example, https://HOSTNAME/user/repo/raw/octocat/Spoon-Knife/master/index.html. Click the Raw button to get the raw URL for a file.
Diff limits
Because diffs can become very large, we impose these limits on diffs for commits, pull requests, and compare views:
- In a pull request, no total diff may exceed 20,000 lines that you can load or 1 MB of raw diff data.
- No single file's diff may exceed 20,000 lines that you can load or 500 KB of raw diff data. Four hundred lines and 20 KB are automatically loaded for a single file.
- The maximum number of files in a single diff is limited to 300.
- The maximum number of renderable files (such as images, PDFs, and GeoJSON files) in a single diff is limited to 25.
Some portions of a limited diff may be displayed, but anything exceeding the limit is not shown.
Commit listings limits
The compare view and pull requests pages display a list of commits between the base and head revisions. These lists are limited to 250 commits. If they exceed that limit, a note indicates that additional commits are present (but they're not shown).