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
| Field | Required | Notes |
|---|---|---|
| Repository name | Yes | Must be unique within your account. Use hyphens for spaces — campus-access, not campus access. |
| Description | No | A short summary that appears on the repository page and in search results. Worth filling in. |
| Visibility | Yes | Public — visible to everyone. Private — visible only to you and invited collaborators. |
| Initialize with a README | No | Recommended — creates a first commit so the repository is not empty and can be cloned immediately. |
| Add .gitignore | No | GitHub offers templates for most languages and frameworks. Select one matching your stack. |
| Choose a licence | No | Relevant 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 / Section | What It Shows |
|---|---|
| Code | The file browser, README, and branch/tag selector |
| Issues | Bug reports, feature requests, and task tracking |
| Pull Requests | Open, closed, and merged PRs |
| Actions | CI/CD workflows |
| Insights | Contributor activity, traffic, dependency graphs |
| Settings | Repository 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:
- Go to the repository Settings tab.
- In the left sidebar, click Collaborators.
- Click Add people and search by username or email.
- 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
mastertomainif 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 option | What it does |
|---|---|
| Require pull request reviews | Changes to this branch must be reviewed and approved before merging |
| Require status checks | CI tests must pass before a PR can be merged |
| Require linear history | No merge commits — only squash or rebase merges allowed |
| Restrict who can push | Only 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):
- Go to Settings → General.
- Scroll to the Default branch section.
- Click the arrows icon next to the branch name and select the new default.
- 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:
- Go to Settings → General → Danger Zone.
- Click Transfer.
- 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.
- Go to Settings → General → Danger Zone.
- Click Delete this repository.
- 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
| Task | Where to do it |
|---|---|
| Create a repository | + menu → New repository |
| Add collaborators | Settings → Collaborators |
| Protect a branch | Settings → Branches → Branch protection rules |
| Change the default branch | Settings → General → Default branch |
| Transfer a repository | Settings → General → Danger Zone → Transfer |
| Delete a repository | Settings → General → Danger Zone → Delete |