Lesson 1 - The Fork-and-Pull-Request Model

Welcome to The Fork-and-Pull-Request Model#

In the last module you pushed to your own repository. But most collaboration involves repositories you don’t own — an open-source project, a teammate’s repo, a company codebase you can’t push to directly. So how do you contribute changes to a project you can’t write to? The answer is the fork-and-pull-request model, and it’s the workflow behind nearly all of open source and a great deal of professional teamwork. The idea: make your own copy (a fork), do your work there, and then politely propose your changes back to the original with a pull request the maintainers can review and merge.

This lesson is the map of that whole process. The next lessons walk each step in detail.

By the end of this lesson, you will be able to:

• Explain why you can’t usually push directly to others’ repositories
• Define a fork and a pull request
• Walk through the fork-and-pull-request lifecycle end to end
• Tell the difference between origin (your fork) and upstream (the original)

You’ll build on remotes from Module 4. Let’s begin.

The Problem: You Can’t Push to What You Don’t Own#

Permissions exist for good reasons. If anyone could push directly to a popular project, its history would be chaos and its security nonexistent. So by default, you have read access to other people’s repositories but not write access — you can clone and read them, but git push will be refused.

That’s exactly the situation the fork-and-pull-request model solves. Instead of needing write access to the original, you get your own writable copy and propose changes back through a channel the maintainers control. They stay in charge of what actually lands; you still get to contribute.

Two Key Ideas: Fork and Pull Request#

• A fork is your personal copy of someone else’s repository, living under your GitHub account. You have full write access to your fork, so you can push to it freely. Creating one is a single click (“Fork”) on GitHub, or gh repo fork with the CLI.
• A pull request (PR) is a proposal: “here are commits on my branch — please review them and, if you’re happy, merge them into your project.” It’s not a Git command but a GitHub feature, and it’s where discussion, review, and approval happen.

Crucially, a pull request is a conversation, not a file dump. Maintainers can comment, ask for changes, and approve — and you can push more commits to address feedback, which update the same PR automatically. (That review process is Lesson 3.)

The Lifecycle, End to End#

Here’s how the whole thing fits together, from spotting something you want to change to seeing it merged:

Read it as six steps:

1. Fork the original repo on GitHub — now you have you/project, a writable copy.
2. Clone your fork to your computer to work on it.
3. Branch and commit your changes locally (always on a feature branch, never directly on main).
4. Push that branch up to your fork.
5. Open a pull request from your fork’s branch to the original repo.
6. The maintainers review and merge it — and your work becomes part of the original project.

Every contribution you make to an open-source project will follow this shape.

origin vs upstream#

This model involves two remotes, and keeping them straight is the one thing beginners trip on:

• origin — your fork. It’s what you cloned from and what you push to. You have write access.
• upstream — the original repo you forked from. You add this remote yourself so you can pull in the project’s latest changes (Lesson 4). You typically only read from it.

So you push to origin (your fork) and pull updates from upstream (the original). Getting these two names right makes the rest of the workflow click.

Practice Exercises#

Exercise 1: Why fork at all?#

You want to fix a typo in a popular open-source project’s README, but git push is refused. Explain why, and what the fork-and-pull-request model lets you do instead.

Exercise 2: Name the remotes#

After forking and cloning, you have two remotes. Which one is origin, which is upstream, and which do you push to?

Exercise 3: Order the steps#

Put these in order: open a pull request, push to your fork, clone your fork, fork the repo, branch and commit.

Summary#

You usually have only read access to other people’s repositories, so you can’t git push to them. The fork-and-pull-request model is the way around that: fork the repo (your own writable copy under your account), clone it, branch and commit your work, push to your fork, then open a pull request proposing your changes to the original — where maintainers review and merge them. Two remotes matter: origin is your fork (you push here) and upstream is the original (you pull updates from here). A pull request is a conversation, not just a code drop.

Key Concepts#

• Fork — your personal, writable copy of someone else’s repository.
• Pull request (PR) — a GitHub proposal to review and merge your changes.
• Lifecycle — fork → clone → branch + commit → push → open PR → review + merge.
• origin vs upstream — your fork (push to) vs the original (pull updates from).

Why This Matters#

The fork-and-pull-request model is how open source works and how countless teams ship code: nothing reaches the main project without review. Mastering it means you can contribute to any public project on GitHub, build a visible track record of real contributions, and participate in the review culture that professional teams run on. It’s arguably the most valuable collaboration skill in this entire course — and the next lessons make each step concrete, starting with opening a pull request.

Next Steps#

Continue Building Your Skills#

You now have the map of the fork-and-pull-request model and the difference between origin and upstream. Next you’ll walk it for real — forking a project, pushing a branch, and opening your first pull request.