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: private or internal.
When you create a repository owned by your personal account, the repository is always private. When you create a repository owned by an organization, you can choose to make the repository private or internal.
- 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. 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."
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 AE. Because of this, limits are set to ensure requests complete in a reasonable amount of time.
Most of the limits below affect both GitHub AE and the API.
Text limits
GitHub displays formatted previews of some files, such as Markdown and Mermaid diagrams. GitHub always attempts to render these previews if the files are small (generally less than 2 MB), but more complex files may time out and either fall back to plain text or not be displayed at all. These files are always available in their raw formats, 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).