Forking & Contributing to Open Source

Open source runs on forks and pull requests. By the end of this lesson you'll fork a project, wire up the origin and upstream remotes, keep your fork in sync, and submit your first real contribution.

Learn Forking & Contributing to Open Source in our free Git course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a…

Part of the free Git course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

1️⃣ Fork and Clone

Click Fork on the project's GitHub page to create github.com/YOU/project — your own copy you can push to. Then git clone your fork's URL. Cloning sets origin to your fork automatically.

2️⃣ Add the upstream Remote

Your fork is frozen at the moment you forked. To track the real project, add it as a second remote called upstream . The convention is simple: push to origin (your fork), pull updates from upstream (the original) .

3️⃣ Keep Your Fork in Sync

Before starting new work, pull the original's latest commits so your branch builds on current code. git fetch upstream downloads them, then you merge (or rebase) upstream/main into your main , and push so your fork matches.

Your turn. Wire up the two remotes after cloning a fork. Fill in the two blanks.

4️⃣ Contribute via Pull Request

Now make your change on a branch, push it to your fork , and open a pull request whose base repository is the original and head is your fork's branch. Tick Allow edits by maintainers so they can polish it if needed.

📋 Quick Reference

No commands given this time — just the plan. Take a small change all the way to a PR on a real project.

Practice quiz

What is a fork on GitHub?

  • A branch in the original repo
  • A deleted repo
  • Your own server-side copy of someone else's repository under your account
  • A type of merge

Answer: Your own server-side copy of someone else's repository under your account. A fork is a full copy of another repo on GitHub, owned by you, that you can push to freely.

Why fork instead of cloning directly when contributing to open source?

  • You usually can't push to a repo you don't own; a fork gives you a copy you CAN push to
  • Forks are faster
  • Cloning is deprecated
  • Forks skip review

Answer: You usually can't push to a repo you don't own; a fork gives you a copy you CAN push to. Without write access you can't push to the original, so you push to your fork and open a PR from it.

After forking, what do you do to get the code on your machine?

  • git fork
  • git pull upstream
  • Nothing
  • git clone <your-fork-url>

Answer: git clone <your-fork-url>. You clone YOUR fork's URL to get a local working copy you can push back to.

By convention, what remote name points at the ORIGINAL project?

  • origin
  • upstream
  • source
  • base

Answer: upstream. By convention origin is your fork and upstream is the original repository you forked from.

What does 'origin' point to in a typical fork setup?

  • Your fork
  • The original repo
  • The main branch
  • Nothing

Answer: Your fork. git clone of your fork sets origin to your fork; you add upstream separately for the original.

How do you add the original project as a remote?

  • git upstream add <url>
  • git remote upstream <url>
  • git remote add upstream <original-url>
  • git fork upstream

Answer: git remote add upstream <original-url>. git remote add upstream <url> registers the original repo so you can fetch its updates.

How do you bring the latest changes from the original into your fork's main?

  • git pull origin
  • git fetch upstream then merge/rebase upstream/main, then push to origin
  • git fork sync
  • git reset upstream

Answer: git fetch upstream then merge/rebase upstream/main, then push to origin. Fetch upstream, integrate upstream/main into your main, then push to keep your fork in sync.

Where do you open a pull request when contributing from a fork?

  • Into your own fork only
  • Into a new repo
  • You email a patch
  • From your fork's branch into the upstream (original) repo

Answer: From your fork's branch into the upstream (original) repo. You push a branch to your fork and open a PR targeting the upstream repository's base branch.

What does 'Allow edits by maintainers' do on a PR from a fork?

  • Deletes your fork
  • Lets the project's maintainers push fixes to your PR branch
  • Auto-merges the PR
  • Hides the PR

Answer: Lets the project's maintainers push fixes to your PR branch. It grants maintainers push access to your PR branch so they can tweak it before merging.

What's a good first step before writing a big contribution?

  • Force-push to upstream
  • Delete the README
  • Read the project's CONTRIBUTING guide and open/claim an issue
  • Rebase upstream/main

Answer: Read the project's CONTRIBUTING guide and open/claim an issue. Checking CONTRIBUTING and discussing in an issue avoids wasted work and respects the project's norms.