Skip to main content
GitHub Flow
CHAPTER 08

Open Source Contribution Workflow

Updated: May 15, 2026
20 min read

# CHAPTER 8

Open Source Contribution Workflow

1. Introduction

The internet runs on Open Source Software (OSS). Frameworks like React, operating systems like Linux, and tools like Git itself are built by thousands of volunteer developers collaborating globally. But how do you collaborate on a project when you don't actually work for the company that owns it? If you find a typo in Facebook's React documentation, you cannot simply git push to their repository—they will reject your unauthorized connection. In this chapter, we will learn the "Fork and Pull" workflow, the standard mechanism for contributing to open-source projects securely and respectfully without requiring administrative access.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Understand the difference between Cloning and Forking.
  • Execute the "Fork and Pull" open-source workflow.
  • Sync a forked repository with the original "Upstream" repository.
  • Navigate open-source contribution guidelines (CONTRIBUTING.md).
  • Understand open-source etiquette and communication standards.

3. Beginner Explanation

Imagine you want to add a new chapter to a famous author's published book.
  • The Problem: You cannot break into the publishing house, erase the author's master copy, and insert your pages.
  • Forking: You go to the library and make a complete photocopy of the book to take to your own house. (This is a *Fork*).
  • Working: You write your new chapter in your photocopied book.
  • The Pull Request: You mail your photocopied chapter to the famous author and say, "I wrote this. If you like it, you can staple it into the official master copy."
  • If the author likes it, they merge it. If they don't, they throw it away. Your local photocopy remains yours to keep.

4. Forking vs. Cloning

This is a critical distinction in GitHub:
  • git clone: Downloads the code to your local laptop. You only do this if you have permission to push back to the repository.
  • Forking: A button on the GitHub website. It copies the entire repository from *Their* GitHub account into *Your* GitHub account. You have full admin rights over your Fork because it belongs to you.

5. The Open Source Workflow (Fork and Pull)

Here is the exact process to fix a bug in a public repository:
  1. 1. Fork: Click the "Fork" button on the target repository on GitHub.
  1. 2. Clone: Clone *your* forked version to your local laptop.
git clone https://github.com/your-username/target-repo.git
  1. 3. Branch: Create a feature branch locally.
git checkout -b bugfix/fix-typo
  1. 4. Commit & Push: Fix the code, commit it, and push it back up to *your* fork on GitHub.
git push origin bugfix/fix-typo
  1. 5. The Cross-Repo PR: Go to the original, official repository on GitHub. You will see a banner allowing you to open a Pull Request *across repositories*—asking the original maintainers to pull the code from your Fork into their Master repo.

6. Mini Project: Simulate Open Source Contribution

Let's practice the cross-repository PR.

Step-by-Step Walkthrough:

  1. 1. Find a public repository on GitHub (e.g., a friend's project, or an open-source tutorial repo).
  1. 2. Click the Fork button in the top right corner. Wait for the copy to generate in your account.
  1. 3. Open your terminal. Clone *your* newly forked URL.
  1. 4. Create a branch: git checkout -b feature/add-my-name
  1. 5. Edit the README to add your name to a "Contributors" list.
  1. 6. Commit and push to your fork.
  1. 7. Go to the original repository on GitHub. Click Compare & pull request.
  1. 8. Ensure the interface shows the base repository as the original, and the head repository as your fork. Write a polite description and submit!

7. Upstream Synchronization

If you fork a massive project like React, and you spend 3 weeks working on your fork, the official React repository will have moved thousands of commits ahead of you. Your fork is now dangerously out of date. You must tell your local Git to track *both* your fork (origin) and the official repo (upstream).
bash
12345678 
# Add the official repo as a secondary remote called "upstream"
git remote add upstream https://github.com/official-owner/target-repo.git

# Download the latest official changes
git fetch upstream

# Merge the official changes into your local main branch
git merge upstream/main

8. Best Practices

  • Read the CONTRIBUTING.md: Massive projects are flooded with hundreds of PRs a day. To manage the chaos, they create a CONTRIBUTING.md file in the root of the repository outlining strict rules (e.g., "All PRs must include automated tests", "Do not submit PRs for grammar fixes"). If you ignore this file, the maintainers will instantly close your PR without reading it. Respect their time.

9. Common Mistakes

  • The Mega-PR: Submitting an unsolicited Pull Request to an open-source project that changes 5,000 lines of code and totally redesigns their architecture will almost always be rejected. Maintainers do not have the time to review massive, unrequested changes. Start small. Fix a typo. Fix a single bug. Build trust with the community first.

10. Exercises

  1. 1. What is the fundamental difference between "Cloning" a repository and "Forking" a repository?
  1. 2. Why is configuring an "Upstream" remote critical when working on a forked repository for an extended period?

11. FAQs

Q: Do I get paid for open-source contributions? A: Usually, no. It is volunteer work. However, having a portfolio showing that your code was accepted and merged into major projects like Linux, React, or Python is the absolute strongest resume a developer can have. It proves to employers that your code meets the highest global standards.

12. Summary

In Chapter 8, we expanded our collaborative horizons beyond our immediate teams to the global open-source community. We learned that unauthorized collaboration requires the "Fork and Pull" methodology, utilizing GitHub to create parallel, admin-controlled copies of massive public projects. We mastered the network architecture of maintaining two remotes—our personal "Origin" and the official "Upstream"—ensuring our local codebase remains synchronized with the global project. Finally, we emphasized that open-source contribution is governed not just by technical skill, but by strict etiquette and adherence to community guidelines.

13. Next Chapter Recommendation

Our code is public, our forks are active, and our robots are deploying automatically. How do we ensure hackers don't exploit this massive ecosystem? Proceed to Chapter 9: Security and Best Practices.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter GitHub Actions Basics
Next Chapter Security and Best Practices

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5