Lesson 2 - Opening a Pull Request

Welcome to Opening a Pull Request#

Lesson 1 gave you the map; this lesson walks it. You’re going to take the whole contributor path from start to finish: fork a project you don’t own, clone your fork, wire up upstream, do your work on a feature branch, push that branch to your fork, and finally open a pull request asking the maintainers to merge your change. By the end you’ll have done the single most common thing a GitHub contributor does — propose a change to someone else’s project.

We’ll work against a practice repo called git-collaboration-practice. The original lives under the datatweets account; your fork will live under your account, which we’ll call you. Every command below is real.

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

• Fork a repository and clone your fork to your computer
• Add the original repo as the upstream remote and verify both remotes
• Create a feature branch, commit, and push it to your fork
• Open a pull request from the GitHub web interface or with gh pr create
• Write a clear PR title and description that explain what and why

Let’s contribute something.

Step 1: Fork and Clone, Then Add upstream#

First you need your own writable copy. On GitHub, open datatweets/git-collaboration-practice and click the Fork button in the top-right; GitHub creates you/git-collaboration-practice under your account. If you prefer the command line, the gh CLI forks and clones in one step:

gh repo fork datatweets/git-collaboration-practice --clone

If you forked in the browser instead, clone your fork yourself:

$ git clone [email protected]:you/git-collaboration-practice.git
Cloning into 'git-collaboration-practice'...
$ cd git-collaboration-practice

Now you have a local clone. Cloning automatically sets one remote — origin, pointing at your fork. But you also want a connection back to the original project so you can pull in its latest changes later (that’s Lesson 4). By convention that remote is named upstream, and you add it yourself:

$ git remote add upstream [email protected]:datatweets/git-collaboration-practice.git

Confirm both remotes are wired correctly with git remote -v:

$ git remote -v
origin    [email protected]:you/git-collaboration-practice.git (fetch)
origin    [email protected]:you/git-collaboration-practice.git (push)
upstream  [email protected]:datatweets/git-collaboration-practice.git (fetch)
upstream  [email protected]:datatweets/git-collaboration-practice.git (push)

That’s exactly the layout you want: origin is your fork (where you push), and upstream is the original (where you’ll fetch updates from). With those two straight, the rest of the workflow falls into place.

Step 2: Branch, Commit, and Push to Your Fork#

Never do your work directly on main. Create a feature branch named for the change you’re making — here we’re adding a priority field to tasks, so add-priority is a clear name. The git switch -c command creates the branch and moves you onto it:

$ git switch -c add-priority
Switched to a new branch 'add-priority'

Make your edit (in this case, to task_manager.py), then stage and commit it as usual:

$ git add task_manager.py
$ git commit -m "Add task priority"

So far everything is local. To turn this into a pull request, the branch has to exist on your fork, so push it up. The first time you push a new branch, use -u (short for --set-upstream) to link your local branch to its counterpart on origin; after that, a plain git push is enough:

$ git push -u origin add-priority
 * [new branch]      add-priority -> add-priority
branch 'add-priority' set up to track 'origin/add-priority'.

Before that confirmation line, Git prints a bit of object-transfer progress as it uploads your commit over the network — counts and percentages that vary by change, so don’t read anything into the exact numbers. What matters is the [new branch] line and the tracking confirmation: your add-priority branch now lives on your fork, ready to become a pull request.

Step 3: Open the Pull Request#

Your branch is on your fork; now you propose it to the original. There are two equivalent ways to do this.

From the GitHub web interface. Right after a push, GitHub notices the new branch and shows a “Compare & pull request” button at the top of your fork’s repo page. Click it and GitHub opens the pull request form, pre-filled so that:

• base = the original repo’s main (datatweets/git-collaboration-practice) — where you want your change to land
• compare = your branch (you:add-priority) — the change you’re proposing

Fill in a title and description, then click “Create pull request”. That’s it — the PR is open and the maintainers are notified.

From the command line. The gh CLI opens the same PR without leaving your terminal. Run gh pr create, specifying the base branch, your head branch, and the title and body:

$ gh pr create --base main --head add-priority \
    --title "Add task priority" \
    --body "Adds an optional priority field to each task."

On success, gh prints the URL of the new pull request — open that link to see your PR on GitHub, exactly as if you’d created it through the web form.

Writing a good title and description#

A pull request is a request to a human, so make their job easy. The title is a short summary of the change — like a good commit subject. The description is where you explain what the change does and, more importantly, why it’s needed. A reviewer who understands your reasoning can approve in seconds; one left guessing has to ask, and that slows everything down.

Compare a vague description with a useful one:

• Weak: “some changes” — tells the reviewer nothing.
• Strong: “Adds an optional priority field to each task so users can mark which items are urgent. Defaults to normal priority, so existing tasks are unaffected.” — states the what, the why, and the impact.

You don’t need an essay. A sentence or two that answers “what changed and why should we want it?” is plenty.

Practice Exercises#

Exercise 1: Wire up the remotes#

You’ve just cloned your fork of git-collaboration-practice. What command adds the original datatweets repo as upstream, and how do you check that both remotes are set correctly?

Exercise 2: Branch, commit, push#

You’re about to make a change. Write the commands to create a feature branch called add-priority, then (after editing and committing) push it to your fork for the first time.

Exercise 3: Open the PR two ways#

Your branch is pushed. Describe how to open the pull request from the GitHub website, and write the equivalent gh pr create command with a clear title and description.

Summary#

To contribute a change to a project you don’t own, you walk a fixed path: fork it on GitHub (or with gh repo fork --clone), clone your fork, and add the original as upstream with git remote add upstream ..., verifying both with git remote -v. Then you create a feature branch with git switch -c, commit your work, and push it to your fork with git push -u origin <branch>. Finally you open a pull request — either the “Compare & pull request” button on GitHub or gh pr create --base main --head <branch> — with a title and description that explain what changed and why. Always work on a branch, never main, because a PR tracks a branch and updates automatically as you push more commits.

Key Concepts#

• origin vs upstream — your fork (push here) vs the original (added manually, fetched from later).
• Feature branch — git switch -c <name>; never commit your contribution on main.
• First push — git push -u origin <branch> links the branch and creates it on your fork.
• Open a PR — the “Compare & pull request” button or gh pr create, with base = original’s main, compare = your branch.
• Good description — explains what the change does and why it’s wanted, so reviewers can act fast.

Why This Matters#

Opening a pull request is the moment your work becomes a proposal a team can act on. Every public contribution you make on GitHub flows through this exact sequence, so getting it smooth — fork, branch, push, PR — turns “I’d like to help” into a real, reviewable change. And a clear title and description aren’t a formality: they’re how you respect a maintainer’s time and get your work merged faster. Next, you’ll see what happens on the other side of that PR — the review.

Next Steps#

Continue Building Your Skills#

You’ve now walked the full contributor path and opened a pull request from both the web and the command line. The PR is open — but it’s the start of a conversation, not the end. In the next lesson you’ll handle code review: reading feedback, requesting and responding to changes, and updating your PR by pushing more commits to the same branch.