Skip to main content

This version of GitHub Enterprise Server was discontinued on 2024-03-26. No patch releases will be made, even for critical security issues. For better performance, improved security, and new features, upgrade to the latest version of GitHub Enterprise Server. For help with the upgrade, contact GitHub Enterprise support.

About repositories

A repository contains all of your code, your files, and each file's revision history. You can discuss and manage your work within the repository.

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.

TermDefinition
BranchA parallel version of your code that is contained within the repository, but does not affect the primary or main branch.
CloneTo download a full copy of a repository's data from your GitHub Enterprise Server instance, including all versions of every file and folder.
ForkA new repository that shares code and visibility settings with the original "upstream" repository.
MergeTo take the changes from one branch and apply them to another.
Pull requestA request to merge changes from one branch into another.
RemoteA repository stored on GitHub Enterprise Server, not on your computer.
UpstreamThe 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.