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.
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.
Discussion & Insights