About repositories
A repository is the most basic element of GitHub. It's a place where you can store your code, your files, and each file's revision history. Repositories can have multiple collaborators and can be either public, internal, or private.
To create a new repository, go to https://github.com/new. For instructions, see "Quickstart for repositories."
Repository terminology
Before getting started with repositories, learn these important terms.
| Term | Definition |
|---|---|
| Branch | A parallel version of your code that is contained within the repository, but does not affect the primary or main branch. |
| Clone | To download a full copy of a repository's data from your GitHub Enterprise Server instance, including all versions of every file and folder. |
| Fork | A new repository that shares code and visibility settings with the original "upstream" repository. |
| Merge | To take the changes from one branch and apply them to another. |
| Pull request | A request to merge changes from one branch into another. |
| Remote | A repository stored on GitHub Enterprise Server, not on your computer. |
| Upstream | The branch on an original repository that has been forked or cloned. The corresponding branch on the cloned or forked branch is called the "downstream." |
About repository ownership
You can own repositories individually, or you can share ownership of repositories with other people in an organization.
In either case, access to repositories is managed by permissions. For more information, see "Permission levels for a personal account repository" and "Repository roles for an organization."
About collaboration
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 Projects (beta) to organize and prioritize your issues and pull requests. For more information, see "About Projects (beta)."
Each person and organization can own unlimited repositories and invite an unlimited number of collaborators to all 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.
By default, enterprise members can fork an internal repository into any organization where the user can create repositories. Organization owners can also allow users to create a fork owned by a user account, and can manage the forking policy for an organization. Enterprise owners can manage the forking policy for some or all organizations within an enterprise. For more information, see "Managing the forking policy for your organization" and "Enforcing repository management policies in your enterprise."
Next steps
Here are some helpful resources for taking your next steps with repositories.
- "Best practices for repositories:" Learn how to use repositories most effectively.
- "Creating a new repository:" Create a new repository.
- "Creating and deleting branches within your repository:" Learn how to create and delete branches within your repository.
- "Creating a pull request:" Create a pull request to propose and collaborate on changes to a repository.