Chapter 32: Git GitHub Fork

GitHub Fork (also called “forking a repository”)

This is the single most common way people start contributing to open-source projects, make their own version of someone else’s code, experiment safely, or even create a template for their own work.

Many beginners hear “fork” and think:

  • “Is it copying the repo?”
  • “Will it break the original?”
  • “How is it different from clone?”
  • “What do I do after I fork?”

Today I’m going to explain it very clearly and slowly, like I’m sitting next to you with both your laptop and GitHub tab open — step by step, with real examples, what the screens look like, and a complete realistic flow you can do right now.

1. What does “fork” actually mean?

Fork = “make your own personal copy of someone else’s entire repository on GitHub”

More precisely:

  • You create an exact copy of the original repository under your GitHub account
  • The copy is independent — you can change anything you want
  • The original repo (upstream) stays completely untouched
  • GitHub keeps a link saying “this is a fork of xyz”
  • You can later send your changes back to the original via a Pull Request (PR)

Analogy most people love:

  • Original repo = a public library book
  • Fork = you make a photocopy of the entire book for yourself
  • You can highlight, write notes, add new chapters in your copy
  • The original book in the library never changes
  • If your notes are good, you can politely send them to the librarian (“pull request”) so they can add them to the official book

2. Fork vs Clone – the most common confusion

Question Fork (on GitHub) Clone (on your laptop)
Where does the copy live? On GitHub under your account On your local computer
Who can see it? Anyone (if public) or only you (if private) Only you (unless you push somewhere)
Can you send changes back? Yes — via Pull Request No — clone is just download
Does it stay in sync? No — you have to manually update it No — you have to pull
Purpose Contribute, customize, experiment publicly Work locally, make changes

Rule of thumb in 2026:

  • Want to contribute or have your own public versionFork first
  • Already have permission or just want local copy → Clone directly

3. Realistic Example – Fork + Make Change + Send Pull Request

Let’s do a safe, beginner-friendly contribution right now.

Target repo (real & welcoming in 2026): https://github.com/public-apis/public-apis (very popular list of free APIs — lots of typos & missing entries)

Goal: Add one missing free API to their README (or fix a typo)

Step 1 – Fork the repository

  1. Go to https://github.com/public-apis/public-apis
  2. Click the Fork button (top-right, near Star & Watch)
  3. Choose your accountCreate fork

Wait 5–30 seconds → you now own: https://github.com/**your-username**/public-apis

Step 2 – Clone your fork locally

Bash

Step 3 – Create a new branch (never work on main!)

Bash

Step 4 – Make a small realistic change

Open README.md → find the “Weather” section

Add one line (example):

Markdown

Save file.

Step 5 – Commit with good message

Bash

Step 6 – Push your branch to your fork

Bash

Step 7 – Create the Pull Request back to original repo

Go to your fork on GitHub: https://github.com/your-username/public-apis

You should see yellow banner:

“add/weather-api-example had recent pushes…”

Click Compare & pull request

Important settings:

  • base repository: public-apis/public-apis ← compare
  • head repository: your-username/public-apis
  • base: main ← compare: add/weather-api-example

Fill nicely:

Title:

text

Description:

text

Click Create pull request

Done! 🎉 Your change is now waiting for review by the maintainers.

What happens next? (real-world flow)

  • Maintainers see your PR (hopefully they have notifications)
  • They review → may merge quickly (especially docs/API additions)
  • May ask: “Can you add more details?” → you edit locally → commit → push → PR auto-updates
  • When happy → Merge pull request (usually squash & merge)
  • Your commit appears in official repo history
  • Your GitHub profile gets contribution points

Quick Fork Contribute Cheat Sheet

  1. Go to repo → Fork
  2. Clone your fork locally
  3. git switch -c fix/something-nice
  4. Make change → commit with good message
  5. git push -u origin your-branch
  6. On GitHub (your fork) → Compare & pull request
  7. Set base = original repo main
  8. Write nice title + description
  9. Submit → wait → respond to feedback

Want to do a real contribution together right now?

I can suggest 5–10 very beginner-friendly repos with “good first issue” label — we can pick one → fix a typo → create PR live.

Or want to see how to update your fork when upstream changes?

Just tell me — we’ll do it step by step. Contributing is one of the fastest ways to learn Git deeply and build your portfolio — you’re going to love it! 🚀

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *