Practical Exercise: Fork a Public Repo, Make Improvements, and Submit a Real PR

This capstone exercise is different from previous ones in an important way: rather than simulating a scenario, it walks through making an actual, real contribution to a genuine public repository — the authentic culmination of everything covered across this module, from forking through code review readiness. By the end, you'll have gone through the complete, real lifecycle of an open-source contribution.

Learning Objectives

• Find and fork a suitable public repository for a genuine first contribution.
• Sync the fork, create a focused feature branch, and make one small, well-scoped improvement.
• Write a clear, well-structured pull request following this module's best practices.
• Understand what to expect during the review process and how to respond to feedback.

Key Terms to Know Before This Fork-and-PR Practical Exercise

• Good first issue: A label (introduced in the GitHub Issues lesson) many projects use to flag tasks specifically suited for new contributors.
• Scope discipline: The practice of deliberately limiting a contribution to exactly what was proposed or agreed upon, avoiding unrelated changes that expand a PR beyond its original focus.
• Contribution guidelines: A project's documented expectations for external contributors, often found in a CONTRIBUTING.md file, covering code style, testing requirements, and the PR process.

How to Fork, Improve, and Submit a Real Pull Request, Step by Step

**Step 1: Find a suitable repository and task.** Look for a public repository with an active maintainer presence (recent commits, responsive issue activity) and, ideally, an issue labeled `good first issue` (Lesson 6, this module) — this signals the maintainers have specifically identified it as approachable for a new contributor. Read the repository's `README.md` (Module 4) and, if present, its `CONTRIBUTING.md` file thoroughly before starting, to understand any specific expectations around code style, testing, or the contribution process.

**Step 2: Fork the repository.** Using GitHub's 'Fork' button (Lesson 1, this module), create your own independent copy with full write access.

**Step 3: Clone your fork and add the upstream remote.**

```
git clone https://github.com/your-username/the-project.git
cd the-project
git remote add upstream https://github.com/original-owner/the-project.git
```

**Step 4: Sync your fork before starting.** Even on a freshly forked repository, it's good practice to confirm you're starting from the absolute latest state (Lesson 2, this module):

```
git fetch upstream
git switch main
git rebase upstream/main
```

**Step 5: Create a small, focused feature branch** for exactly the one change you intend to make — no more, no less, respecting the scope discipline emphasized in this module's PR best practices lesson:

```
git switch -c fix/correct-typo-in-installation-docs
```

**Step 6: Make your focused change, following the project's existing code style and conventions**, and commit it with a clear, atomic commit message (Module 1):

```
git add README.md
git commit -m "docs: fix typo in installation instructions"
```

**Step 7: Push your branch to your own fork** (not the original repository, which you don't have write access to):

```
git push -u origin fix/correct-typo-in-installation-docs
```

**Step 8: Open a pull request**, with `base: main` on the *original* repository and `compare: fix/correct-typo-in-installation-docs` from *your fork*. Write a clear title and description (Lessons 3-4, this module), link any related issue with a closing keyword if applicable, and fill out the repository's PR template if one exists.

**Step 9: Respond to code review.** A maintainer may leave comments, suggested changes, or request modifications (Lesson 5, this module). Address feedback by pushing additional commits to the *same branch* — they'll automatically appear in the existing pull request, exactly as covered earlier this module.

**Step 10: Understand what happens next.** If accepted, a maintainer will merge your pull request using whichever strategy the project prefers (Lesson 11, this module) — at which point your contribution becomes a permanent part of that project's real history. If ultimately not accepted, that's a completely normal, valuable part of the process too — you've still gained genuine, practical experience with the entire real-world contribution workflow.

Fork-to-Pull-Request Workflow: Visual Walkthrough

Draw a ten-step numbered vertical flow: 1) Find a repo + good first issue → 2) Fork on GitHub → 3) Clone fork + add upstream remote → 4) Sync fork (fetch upstream, rebase) → 5) Create a small, focused feature branch → 6) Make the change, commit with a clear message → 7) Push branch to origin (your fork) → 8) Open PR: base=original repo's main, compare=your fork's branch → 9) Respond to review feedback via new commits on the same branch → 10) PR merged (or valuable feedback received either way).

Fork-and-PR Exercise Steps: Quick Reference Table

Step	Command / Action	Purpose
1. Find repo + task	Look for 'good first issue' label	Ensures a genuinely approachable, welcomed contribution
2-3. Fork + clone + upstream	GitHub Fork button, git clone, git remote add upstream	Sets up your independent, writable copy with sync capability
4. Sync before starting	git fetch upstream, git rebase upstream/main	Ensures you're building on the latest code
5-6. Branch + change + commit	git switch -c <branch>, edit, git commit	One small, focused, well-scoped change
7-8. Push + open PR	git push -u origin <branch>, open PR on GitHub	Proposes your fork's branch be merged into the original repo
9. Respond to review	Push new commits to the same branch	Addresses feedback within the existing, already-open PR

Forking, Branching, and Submitting a PR: Command Syntax

# Step 2-3: Fork on GitHub's website first, then:
git clone https://github.com/your-username/the-project.git
cd the-project
git remote add upstream https://github.com/original-owner/the-project.git

# Step 4: Sync before starting
git fetch upstream
git switch main
git rebase upstream/main

# Step 5-6: Small, focused branch and change
git switch -c fix/correct-typo-in-installation-docs
# ... edit README.md ...
git add README.md
git commit -m "docs: fix typo in installation instructions"

# Step 7: Push to YOUR fork
git push -u origin fix/correct-typo-in-installation-docs

# Step 8: Open PR on GitHub (base: original repo's main, compare: your branch)

# Step 9: If feedback is given, push more commits to the SAME branch
git add README.md
git commit -m "docs: apply reviewer's suggested phrasing"
git push

Breaking Down the Fork-and-PR Exercise Example

This sequence represents the complete, authentic version of the fork-and-pull-request workflow first introduced conceptually in Lesson 1 of this module, now applied end to end with every intermediate concept from the module folded in: syncing before starting (Lesson 2), a small, focused branch respecting scope discipline (Lesson 4), a clear atomic commit (Module 1's principles applied here), pushing to origin rather than attempting to push to the original repository directly (Lesson 1's core distinction), and finally responding to any review feedback by pushing further commits to the same branch, which automatically update the already-open pull request (Lesson 3).

How This Exact Workflow Powers Real Open-Source Contributions

• This exact sequence is precisely how the overwhelming majority of first-time open-source contributions happen in practice, from a one-line documentation fix to a developer's very first meaningful code contribution to a project they use and admire.
• Many companies now explicitly encourage or even require engineers to make a genuine open-source contribution as part of onboarding or professional development, specifically because it exercises this exact real-world collaborative workflow.
• Hiring managers and technical interviewers sometimes ask candidates to walk through a real pull request they've submitted, using it as concrete evidence of practical Git and collaboration fluency beyond just theoretical knowledge.
• Maintainers of beginner-friendly open-source projects deliberately curate 'good first issue' labels specifically to create exactly this kind of safe, welcoming on-ramp for someone's very first real-world contribution.

Fork-and-PR Practical Exercise Interview Questions and Answers

Q1. Walk me through the complete process of contributing a small fix to an open-source project you don't have write access to.

Find a suitable repository and task (ideally a 'good first issue'), fork it on GitHub to get a writable copy, clone your fork locally and add the original repository as an 'upstream' remote, sync with upstream before starting to ensure you're building on the latest code, create a small, focused feature branch for exactly one change, make and commit that change with a clear message, push the branch to your own fork (origin), and open a pull request proposing your fork's branch be merged into the original repository's base branch.

Q2. If a maintainer requests changes on your pull request, what is the correct way to address that feedback?

Push additional commits to the same branch that the pull request is already open from. These new commits automatically appear within the existing, already-open pull request — there's no need to close it and open a new one.

Q3. Why is it important to keep a first-time contribution small and focused, rather than including several unrelated improvements at once?

Small, focused pull requests are significantly easier and faster for a maintainer to review thoroughly, increasing the likelihood of a smooth, positive first contribution experience. Bundling several unrelated changes together makes review harder and increases the risk of the PR being rejected or requiring significant rework.

Fork-and-PR Practical Exercise Quiz: Test Your Understanding

1. In this exercise, why do you push your feature branch to 'origin' rather than the original repository directly?

1. Because pushing to the original repository is technically impossible in all cases
2. Because you typically don't have write access to the original repository; origin refers to your own fork, which you do have write access to
3. Because 'origin' is required by Git for all pushes regardless of context
4. Because the original repository doesn't accept any pull requests

Answer: B. Because you typically don't have write access to the original repository; origin refers to your own fork, which you do have write access to

Explanation: Consistent with the origin/upstream vocabulary from this module, you push to origin (your own fork) since you have full write access there, then propose merging into the original (upstream) repository via a pull request.

2. Why is it recommended to sync your fork with upstream before starting a new contribution, even right after forking?

1. It's not actually necessary if you just forked
2. To ensure you're building your change on top of the most current version of the project, minimizing future conflict risk
3. It automatically submits your pull request
4. It deletes your fork if skipped

Answer: B. To ensure you're building your change on top of the most current version of the project, minimizing future conflict risk

Explanation: Even a freshly created fork can be behind if the original repository has received new commits since forking; syncing first ensures your contribution builds on the latest code, reducing the chance of painful conflicts later.

3. If a maintainer requests changes on your pull request, what should you do?

1. Close the pull request and open a completely new one
2. Push additional commits addressing the feedback to the same branch, which automatically updates the existing PR
3. Delete your fork and start over
4. Nothing — the PR will update itself automatically without any action

Answer: B. Push additional commits addressing the feedback to the same branch, which automatically updates the existing PR

Explanation: Since a pull request is tied to a branch rather than a fixed snapshot, pushing new commits to that same branch automatically incorporates them into the existing, already-open pull request.

Common Mistakes When Submitting Your First Real Pull Request

• Choosing an overly large or ambitious first contribution, rather than starting with something genuinely small and well-scoped.
• Skipping the project's CONTRIBUTING.md or existing code style conventions, submitting a change that doesn't match the project's established patterns.
• Attempting to push directly to the original repository instead of your own fork, running into a permission error.
• Closing and reopening a new pull request after receiving review feedback, instead of simply pushing new commits to the existing branch.

Fork-and-PR Exercise: Exam-Ready Quick Notes

• Correct sequence: find task → fork → clone + add upstream → sync (fetch/rebase) → small focused branch → commit → push to origin → open PR (base: original, compare: your fork's branch) → respond to feedback via new commits on the same branch.
• Push to origin (your fork), never directly to the original (upstream) repository, since you lack write access there.
• Syncing before starting, even on a fresh fork, minimizes future conflict risk.
• Review feedback is addressed by pushing new commits to the same branch — no need to close/reopen the PR.

Fork-and-PR Exercise: Key Takeaways

• This exercise represents the complete, authentic real-world workflow for contributing to any project you don't have direct write access to.
• Every concept from this module — forking, syncing, PR anatomy, best practices, and responding to review — comes together in this one end-to-end process.
• Completing a genuine first contribution, however small, is one of the most concrete, resume-worthy demonstrations of practical Git and GitHub collaboration skill.

Frequently Asked Questions About Submitting Your First Pull Request

Q1. What is a good first step for finding a suitable project to contribute to?

Look for a public repository with active maintainer engagement and, ideally, an issue labeled 'good first issue' — this signals the maintainers have specifically identified it as approachable and welcoming for a new contributor.

Q2. Why do I need to fork the repository instead of just cloning it directly?

Since you don't have direct write access to the original repository, forking gives you your own independent, fully writable copy that you can push changes to, which you can then propose merging back via a pull request.

Q3. Should I sync my fork with the original repository even if I just created it?

Yes, it's still good practice, since the original repository may have received new commits since the moment you forked it. Syncing first ensures your contribution builds on the most current code, reducing the risk of a painful conflict later.

Q4. What should I do if a maintainer requests changes to my pull request?

Push additional commits addressing their feedback to the same branch your pull request is already open from — these new commits will automatically appear within the existing pull request, with no need to close and reopen anything.

Q5. What happens if my pull request isn't accepted?

That's a completely normal and valuable part of the process. You'll still have gained genuine, practical experience with the entire real-world contribution workflow — forking, branching, committing, and navigating code review — which is valuable regardless of whether this specific contribution was ultimately merged.

Summary

This capstone exercise walks through submitting an authentic, real pull request to a genuine public repository, integrating every concept from this module into one complete, real-world workflow: finding a suitable repository and task (ideally a 'good first issue'), forking it to gain write access, cloning the fork and adding the original repository as an `upstream` remote, syncing with upstream before starting to minimize future conflict risk, creating a small, focused feature branch for exactly one change, committing it with a clear message, pushing the branch to `origin` (your own fork, since you lack direct write access to the original), and opening a pull request with a clear title and description, following this module's best practices. Any review feedback is addressed by pushing additional commits to the same branch, which automatically update the existing, already-open pull request. Whether ultimately merged or not, completing this exercise represents genuine, practical experience with the exact real-world workflow underlying the vast majority of open-source and cross-team collaboration on GitHub.