Fork a GitHub Repo & Submit Your First PR

Research-backed — sourced directly from GitHub’s own official documentation (docs.github.com), checked 5 October 2026. This is a step-by-step walkthrough of GitHub’s own documented fork-and-pull-request flow, not a hands-on test record of a specific pull request, since opening a real PR on someone else’s project is a real public action this guide leaves to you.

The problem

You found an open-source project with a typo in its README, or a small bug you know how to fix, and you want to send that fix back — but “fork it and open a pull request” is four words that hide about a dozen small steps for someone who has never done it.

Expected outcome

By the end of this guide you will have your own copy (a “fork”) of a public GitHub repository, a small saved change inside it, and a real pull request open against the original project, using nothing but a free GitHub account and Git.

Requirements and costs

A free GitHub account.
Git installed on your computer (free, from git-scm.com).
Cost: free. Forking, cloning and opening pull requests cost nothing on GitHub, for public repositories.

Unfamiliar terms, explained

Repository (repo) — a project’s folder of code, tracked by Git.
Fork — your own personal copy of someone else’s repository, under your account.
Clone — downloading a copy of a repository onto your own computer.
Branch — a separate line of changes inside a repository, so your edit doesn’t sit directly on the main version.
Commit — a saved snapshot of your changes, with a short message describing what changed.
Pull request (PR) — a request asking the original project to pull your changes from your fork into theirs.

Step-by-step implementation

Find the repository you want to contribute to and click Fork in the top right of its GitHub page. This creates your own copy under your account.

Clone your fork to your computer:

git clone https://github.com/YOUR-USERNAME/REPO-NAME.git
cd REPO-NAME

Create a new branch for your change — never commit directly to main:
```
git checkout -b fix-readme-typo
```
Make your change in a text editor, then check what changed:
```
git status
git diff
```

Commit the change with a short, honest description:

git add .
git commit -m "Fix typo in installation section of README"

Push your branch to your fork on GitHub:
```
git push origin fix-readme-typo
```
Open the pull request. GitHub shows a “Compare & pull request” button on your fork’s page right after a push — click it, write a short description of what you changed and why, and submit.
Wait for review. The project’s maintainers will comment, approve, request changes, or (occasionally) close it without merging — all of these are a normal part of the process, not a failure on your part.

What you should see when it works

After pushing your branch, GitHub’s own page for your fork shows a yellow banner with your branch name and a green “Compare & pull request” button. After submitting, the pull request gets its own page and number (like #1234) on the original repository, visible in its “Pull requests” tab.

Common problems and fixes

“Permission denied” when pushing. You’re trying to push to the original repository instead of your fork — check your remote URL with git remote -v; it should point to YOUR-USERNAME/REPO-NAME, not the original owner’s.
Your fork is behind the original repository. Add the original as a second remote and pull its latest changes before you branch:
```
git remote add upstream https://github.com/ORIGINAL-OWNER/REPO-NAME.git
git fetch upstream
git merge upstream/main
```
Your pull request shows merge conflicts. This means the original project changed the same lines you did since you forked. Pull the latest upstream/main (above), resolve the conflicting lines in your editor, commit, and push again — the pull request updates automatically.
Nobody responds to your pull request. Open-source maintainers are often volunteers with limited time. A polite comment after a few weeks is reasonable; repeatedly pinging is not.

Free vs. paid

Everything above is free on GitHub for public repositories, with no account tier required. GitHub’s paid plans (Team, Enterprise) add private-repository collaboration features that have nothing to do with contributing to public open-source projects.

What to do next

Start with something small and verifiable — a documentation fix, a typo, a clearly described bug with a one-line fix — before attempting a larger feature. Small, well-described pull requests get reviewed and merged far more often than large, unexplained ones.

Free resources

The download is a one-page checklist to run through before you click “Create pull request,” covering the most common reasons a first PR gets stuck in review.

Download the first pull request checklist (ZIP, 1 KB)

Is there a paid version?

Not yet. This is the complete method. TNT Review has sold nothing to date and has no checkout, so any price we discuss in future should be read as a hypothesis, not an offer.

How to Fork a GitHub Repo and Submit Your First Pull Request