Last updated: 2026-05-19

Creating and Managing Repositories

A repository on GitHub is the remote home for your project. It stores your complete Git history, hosts your branches and tags, and provides the interface through which collaborators interact with your work. Knowing how to create, configure, and maintain a repository well is foundational to using GitHub effectively.


Creating a New Repository

To create a repository, click the + icon in the top-right navigation bar and select New repository, or click the New button on your repositories page.

The new repository form

FieldRequiredNotes
Repository nameYesMust be unique within your account. Use hyphens for spaces — campus-access, not campus access.
DescriptionNoA short summary that appears on the repository page and in search results. Worth filling in.
VisibilityYesPublic — visible to everyone. Private — visible only to you and invited collaborators.
Initialize with a READMENoRecommended — creates a first commit so the repository is not empty and can be cloned immediately.
Add .gitignoreNoGitHub offers templates for most languages and frameworks. Select one matching your stack.
Choose a licenceNoRelevant for public projects. Defines how others can use your code.

After clicking Create repository, the repository exists at:

https://github.com/<username>/<repository-name>

And is accessible over SSH at:

git@github.com:<username>/<repository-name>.git

Connecting a Local Project to the New Repository

If you selected "Initialize with a README," GitHub creates a first commit for you. Clone the repository to start working:

git clone git@github.com:username/repository-name.git
cd repository-name

If you already have a local project and want to push it to the new GitHub repository:

cd existing-project
git init
git add .
git commit -m "Initial commit"
git remote add origin git@github.com:username/repository-name.git
git push -u origin main

The Repository Page

Once a repository exists, its GitHub page is the central hub for everything related to it:

Tab / SectionWhat It Shows
CodeThe file browser, README, and branch/tag selector
IssuesBug reports, feature requests, and task tracking
Pull RequestsOpen, closed, and merged PRs
ActionsCI/CD workflows
InsightsContributor activity, traffic, dependency graphs
SettingsRepository configuration — visibility, collaborators, branches, and more

The README file, if present, renders automatically below the file browser on the Code tab — this is the first thing visitors see.


Special Files GitHub Recognises

GitHub gives special treatment to certain files when they are present in the root of a repository. These are not required, but they significantly improve the experience for contributors and visitors.

README

The README is the front page of your project. GitHub renders it automatically on the repository landing page. A good README typically covers:

  • What the project is and what problem it solves.
  • How to install or set it up.
  • How to use it — with examples.
  • The licence it is released under.
  • How to contribute.

GitHub accepts README files in several formats: README.md (Markdown), README.txt, README.asciidoc, and others. Markdown is the standard.

CONTRIBUTING

If a file named CONTRIBUTING (or CONTRIBUTING.md) exists in the repository, GitHub surfaces it automatically when anyone opens a pull request — displaying a prompt that links to it before the PR form is filled in. This is how maintainers communicate their contribution guidelines: coding standards, commit message conventions, testing requirements, or anything else contributors should know before submitting work.

LICENSE

A LICENSE file tells visitors and contributors under what terms they can use, modify, and distribute your code. Without a licence, a public repository defaults to "all rights reserved" — others technically cannot legally use it. GitHub provides a licence picker during repository creation that generates the correct file for common licences (MIT, Apache 2.0, GPL, etc.).

.gitignore

GitHub's .gitignore template picker during repository creation populates this file with the common exclusions for your chosen language or framework. If you did not add one during creation, you can create it manually — or use gitignore.io to generate one.


Adding Collaborators

By default, only you can push to your repository. To give others write access:

  1. Go to the repository Settings tab.
  2. In the left sidebar, click Collaborators.
  3. Click Add people and search by username or email.
  4. The invited person receives an email — they must accept the invitation before gaining access.

Collaborators with write access can push directly to the repository, create branches, and merge pull requests. They do not have access to administrative settings (that requires being an admin or owner).

To remove a collaborator, click the Remove button next to their name on the same page.


Repository Settings

The Settings tab is where you configure how the repository behaves. Key settings worth knowing:

General

  • Repository name — rename the repository. GitHub automatically redirects old URLs.
  • Default branch — change which branch is shown by default and checked out when someone clones. Change this from master to main if needed.
  • Features — enable or disable Issues, Projects, and the Wiki for this repository.
  • Danger Zone — archive, transfer ownership, or delete the repository.

Branches

The Branches section lets you set branch protection rules — rules that prevent certain actions on important branches like main:

Protection optionWhat it does
Require pull request reviewsChanges to this branch must be reviewed and approved before merging
Require status checksCI tests must pass before a PR can be merged
Require linear historyNo merge commits — only squash or rebase merges allowed
Restrict who can pushOnly specific people or teams can push directly

Branch protection rules are one of the most important settings for collaborative repositories — they enforce a minimum standard of quality before code reaches the main branch.


Changing the Default Branch

If your repository uses main but was initialised with master (or vice versa):

  1. Go to SettingsGeneral.
  2. Scroll to the Default branch section.
  3. Click the arrows icon next to the branch name and select the new default.
  4. Confirm the change.

The new default is what gets checked out when someone clones the repository and what pull requests target by default.


Transferring a Repository

If you want to move a repository to a different user account or organisation:

  1. Go to SettingsGeneralDanger Zone.
  2. Click Transfer.
  3. Enter the destination username or organisation name and confirm.

When a repository is transferred:

  • It moves to the new owner's account with all its stars, watchers, issues, and pull requests intact.
  • GitHub sets up automatic redirects from the old URL to the new one — existing clones and remotes continue to work.
  • You lose admin access unless the new owner grants it back.

Deleting a Repository

Deleting a repository is permanent and irreversible. It removes all code, history, issues, pull requests, and settings.

  1. Go to SettingsGeneralDanger Zone.
  2. Click Delete this repository.
  3. Type the repository name to confirm.

GitHub requires you to type the full repository name as a confirmation step precisely because this cannot be undone.


Summary

TaskWhere to do it
Create a repository+ menu → New repository
Add collaboratorsSettings → Collaborators
Protect a branchSettings → Branches → Branch protection rules
Change the default branchSettings → General → Default branch
Transfer a repositorySettings → General → Danger Zone → Transfer
Delete a repositorySettings → General → Danger Zone → Delete