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 user account repository" and "Repository roles for an organization."
With GitHub Free for user accounts and organizations, you can work with unlimited collaborators on unlimited public repositories with a full feature set, or unlimited private repositories with a limited feature set. To get advanced tooling for private repositories, you can upgrade to GitHub Pro, GitHub Team, or GitHub Enterprise Cloud. For more information, see "GitHub's products."
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 GitHub Discussions to ask and answer questions, share information, make announcements, and conduct or participate in conversations about a project. For more information, see "About discussions."
- 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."
Repositories and individual files are subject to size limits. For more information, see "What is my disk quota?"
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 that is owned by an enterprise account, you can also choose to make the repository internal.
Public repositories are accessible to everyone on the internet. 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 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."
Note: Internal repositories are available on GitHub Enterprise Cloud for organizations that are owned by an enterprise account and GitHub Enterprise Server 2.20+. For more information, see "GitHub's products and "About enterprise accounts" in the GitHub Enterprise Cloud documentation.
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 outside of the enterprise, including outside collaborators on organization repositories. For more information, see "Roles in an enterprise" and "Repository roles for an organization."
Internal repositories are the default setting for all new repositories created in an organization owned by an enterprise account.
Any member of the enterprise can fork any internal repository owned by an organization in the enterprise. The forked repository will belong to the member's user 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.
Certain types of resources can be quite large, requiring excessive processing on GitHub. Because of this, limits are set to ensure requests complete in a reasonable amount of time.
Most of the limits below affect both GitHub and the API.
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
raw.githubusercontent.com; for example,
https://raw.githubusercontent.com/octocat/Spoon-Knife/master/index.html. Click the Raw button to get the raw URL for a file.
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.
The compare view and pull requests pages display a list of commits between the
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).