Forks and Pull Requests (Conceptual)

The Hook (The "Byte-Sized" Intro)

Linux has 15,000+ contributors. React has 1,600+. How do thousands of strangers collaborate on the same codebase without chaos? Forks and pull requests. A fork gives you your own copy to experiment on. A PR is your formal proposal to merge your changes back. Together, they're the engine behind open-source software and most corporate development workflows.

📖 What are Forks and Pull Requests?

A fork is a server-side copy of someone else's repository under your account. A pull request (PR) is a proposal to merge changes from your fork (or branch) into the original repository. PRs enable code review, discussion, and automated checks before changes reach the main codebase.

Conceptual Clarity

Fork:

A fork is a full copy of a repository on GitHub/GitLab/Bitbucket
It lives under YOUR account — you have full write access
It stays connected to the original repo so you can sync changes
Forks are a platform feature (GitHub/GitLab), not a core Git concept

Pull Request (Merge Request on GitLab):

A PR says: "I made changes in my fork/branch — please review and merge them"
It shows the diff, enables line-by-line comments, and tracks discussions
CI/CD can run automatically on PRs before merging
PRs can require approvals before merging (branch protection rules)

Real-Life Analogy

Fork = Photocopying a recipe book. You now have your own copy to annotate, modify, and experiment with — the original stays untouched.
Pull Request = Writing a letter to the original author saying "I improved your carbonara recipe — here's my version, want to include it?" The author reviews your changes, suggests edits, and decides whether to accept.

Visual Architecture

Why It Matters

Open source: Forks let anyone contribute without needing write access to the original repo.
Code review: PRs ensure every change is reviewed before merging — catching bugs early.
Quality gates: CI runs on PRs automatically, preventing broken code from reaching main.
Documentation: PR history serves as a record of why changes were made (discussions + diffs).

Code

bash

# ─── Fork + Clone + Contribute workflow ───

# 1. Fork the repo on GitHub (click "Fork" button)

# 2. Clone YOUR fork
git clone git@github.com:YOUR-USERNAME/repo.git
cd repo

# 3. Add the original repo as "upstream"
git remote add upstream https://github.com/ORIGINAL-OWNER/repo.git

# 4. Create a feature branch
git switch -c feature/add-search

# 5. Make changes and commit
git add .
git commit -m "Add search functionality"

# 6. Push to YOUR fork
git push -u origin feature/add-search

# 7. Open a Pull Request on GitHub
# GitHub shows a "Compare & pull request" button automatically

# ─── Keeping your fork in sync ───
git fetch upstream
git switch main
git merge upstream/main
git push origin main
# Your fork's main is now up-to-date with the original

Fork vs Clone vs Branch

Concept	What It Is	Where It Lives	Use Case
Fork	Copy of a repo under your account	Server (GitHub)	Contributing to repos you don't own
Clone	Copy of a repo on your machine	Local machine	Working on any repo locally
Branch	Pointer to a commit within a repo	Inside a repo	Parallel work within the same project

Key Takeaways

Forks are server-side copies that let you contribute without write access to the original.
Pull requests are proposals to merge your changes — they enable review, discussion, and CI.
The workflow: Fork → Clone → Branch → Commit → Push → PR.
Keep your fork in sync with the original using an upstream remote.

Interview Prep

Q: What is the difference between a fork and a clone? A: A fork creates a server-side copy of a repository under your GitHub account — you own it and can push freely. A clone creates a local copy on your machine. You typically fork first (server), then clone your fork (local) to work on it.
Q: Why are pull requests important in team development? A: Pull requests provide a structured way to propose, review, and discuss code changes before they're merged. They enable line-by-line code review, automated CI/CD checks, approval workflows, and serve as documentation of why changes were made.
Q: How do you keep a fork up-to-date with the original repository? A: Add the original repo as an upstream remote (git remote add upstream <URL>), then periodically run git fetch upstream followed by git merge upstream/main into your local main branch, and push to your fork with git push origin main.