☕ Buy a Coffee
Home / Productivity & Coding

GitHub: How to 'Fork' and 'Pull Request' for Beginners

The step-by-step contribution workflow to fork open-source repositories, commit changes on feature branches, and submit PRs.

Sachin Siju
Sachin Siju
Lead Systems Engineer & Tech Blogger
Jul 08, 2026 4 min read
GitHub: How to 'Fork' and 'Pull Request' for Beginners

Contributing to a Repository You Don't Own

You cannot push directly to most open-source projects — you do not have write access to their repository, and that is intentional. The standard contribution workflow instead has you copy the repository into your own account (a fork), make your changes there, and then ask the original project to review and merge them (a pull request). This guide walks through the whole cycle end to end.

Step 1: Fork the Repository

Navigate to the repository on GitHub and click the Fork button in the top-right corner of the page. GitHub creates a full copy of the repository under your own account — for example, forking octocat/hello-world gives you your-username/hello-world, with its own separate history that starts identical to the original but that you now have full write access to.

Step 2: Clone Your Fork Locally

Clone your fork — not the original repository — to your machine:

git clone https://github.com/your-username/hello-world.git
cd hello-world

Step 3: Add the Original Repo as a Remote

The original repository is usually called "upstream" by convention. Add it as a second remote so you can pull in updates from the real project later:

git remote add upstream https://github.com/octocat/hello-world.git

Confirm both remotes are set correctly:

git remote -v
origin    https://github.com/your-username/hello-world.git (fetch)
origin    https://github.com/your-username/hello-world.git (push)
upstream  https://github.com/octocat/hello-world.git (fetch)
upstream  https://github.com/octocat/hello-world.git (push)

Step 4: Create a Feature Branch

Never commit directly to your fork's main branch — keep it clean so it can always be synced with upstream. Create a dedicated branch for your change instead:

git checkout -b fix-typo-in-readme

Use a branch name that describes the change, not something generic like patch-1 — it makes your pull request easier to identify later, both for you and for the maintainer reviewing it.

Step 5: Make Your Changes and Commit

Edit the files you need to change, then stage and commit:

git add README.md
git commit -m "Fix typo in installation instructions"

Write a clear, specific commit message. "Fix bug" tells a reviewer nothing; "Fix null check in parseConfig() when file is empty" tells them exactly what changed and why.

Step 6: Push the Branch to Your Fork

git push origin fix-typo-in-readme

Note this pushes to origin (your fork), never to upstream (the original project) — you almost certainly do not have write access to push there directly, which is the entire reason forks exist.

Step 7: Open the Pull Request

Go to your fork on GitHub. It usually shows a yellow banner offering to Compare & pull request for the branch you just pushed — click it. If the banner does not appear, go to the Pull requests tab and click New pull request manually.

Confirm the base repository is the original project (octocat/hello-world, base branch usually main) and the compare branch is your fork's feature branch. Write a title and description explaining what the change does and why. Then click Create pull request.

Step 8: Respond to Review Feedback

Maintainers may request changes before merging. Make the requested edits on the same local branch, commit, and push again:

git add .
git commit -m "Address review feedback: rename variable for clarity"
git push origin fix-typo-in-readme

The pull request updates automatically with your new commits — you do not need to open a new one.

Step 9: Keep Your Fork in Sync

Over time, the original repository moves forward with commits you do not have. Before starting new work, sync your fork's main branch with upstream:

git checkout main
git fetch upstream
git merge upstream/main
git push origin main

Do this regularly, and always branch new work off an up-to-date main — it drastically reduces the chance of a messy merge conflict later.

Tip: Before opening your first pull request on any project, check for a CONTRIBUTING.md file in the repository root. Most active open-source projects document exact expectations there — commit message format, whether tests are required, coding style, and how they want branches named.

After the Merge

Once a maintainer merges your pull request, your feature branch has served its purpose. Delete it both locally and on your fork to keep things tidy:

git branch -d fix-typo-in-readme
git push origin --delete fix-typo-in-readme

Sync your fork's main with upstream again, and you are ready to start the cycle over for the next contribution.

Featured Infrastructure Partner

Deploy on High-Performance Hostinger Cloud

Get up to 75% OFF + free domain & SSL. Powering xube.me's sub-second response times.

Claim Discount ↗

Discussion & Insights

Related Technical Essays