Forks and open source
Contribute to projects you can’t push to, keep your fork in sync, and understand open-source licenses and etiquette.
- Contribute through a fork: clone, branch, push, and open a pull request upstream
- Keep a fork in sync with the upstream repository
- Choose an open-source license and follow community norms
You can’t push to a repository you don’t have write access to - which is most of the open-source world. Instead you fork it: GitHub makes a copy under your account that you can push to, and your pull request goes from your fork back to the original, called upstream.
1# Fork on GitHub first (or: gh repo fork dungeon-dash/dungeon-dash --clone)
2git clone git@github.com:you/dungeon-dash.git
3cd dungeon-dash
4git remote add upstream https://github.com/dungeon-dash/dungeon-dash.git
5
6git switch -c fix/typo-in-controls
7# ...fix, commit...
8git push -u origin fix/typo-in-controls # to YOUR fork
9gh pr create --repo dungeon-dash/dungeon-dash # PR from your fork to upstream
10
11# Later: bring your fork's main up to date with upstream
12git switch main
13git fetch upstream
14git merge --ff-only upstream/main # or the "Sync fork" button on GitHub
15git push origin mainTwo remotes now: origin (your fork, where you push) and upstream (the original, where you fetch from). Before starting new work, sync main with upstream and branch from that, so your PR doesn’t carry stale history. GitHub shows how far your fork is “ahead” and “behind” upstream on the repository page.
Open-source licenses
A license is what turns “public” into “open source”: it grants everyone permission to use, change and share the code, under conditions. The common ones:
| License | In a sentence |
|---|---|
| MIT | do almost anything, just keep the copyright notice - short and permissive |
| Apache 2.0 | permissive like MIT, plus an explicit patent grant |
| GPL 3.0 | “copyleft”: if you distribute modified versions, they must be GPL too, with source |
| AGPL 3.0 | GPL that also applies when the software is offered over a network |
| No license | all rights reserved - nobody may legally reuse it |
GitHub reads the LICENSE file and shows the license on the repository page; choosealicense.com helps you pick.
Try it
Permissive or copyleft?
Sort each situation by the kind of license it describes.
“A company may use the code in a closed-source product, keeping the notice”
“If you ship a modified version, you must share its source under the same license”
“A public repository with no LICENSE file”
“Includes an explicit grant of the contributors’ patent rights”
“Running a modified version as a web service requires offering its source to users”
““You may look, but not copy or modify””
Being a good open-source citizen
- Read
CONTRIBUTING.mdfirst: it explains how the project wants contributions (tests, commit style, sign-offs). - Look for “good first issue” labels, and comment before starting big work - someone may already be on it, or the maintainers may want a different approach.
- Follow the code of conduct (
CODE_OF_CONDUCT.md). Maintainers are often volunteers; patience and kindness go far. - Small PRs merge. A focused fix is far likelier to be accepted than a giant rewrite.
- Projects you depend on can be supported through GitHub Sponsors.
Key takeaways
Fork to get a copy you can push to; open PRs from your fork back to upstream.
Add the original as
upstreamand sync main with it before starting new work.Licenses make code open source: MIT and Apache are permissive, the GPL is copyleft.
Read CONTRIBUTING.md, start with good first issues, and keep PRs small and kind.
Lesson quiz
7 questions · pass with 5 correct · up to 50 XP
Passing this quiz completes the lesson and keeps your streak going. Questions you miss come back in review sessions later.
Practice: automate GitHub chores with Python
Real GitHub work involves lots of small automation: matching CODEOWNERS, expanding build matrices, bumping versions, reading the API. Write those helpers in Python and run them against sample inputs - locally in your browser, with no GitHub account needed.
Ahead and behind
GitHub tells you your fork is “3 commits ahead, 2 behind”. The input has two lines, upstream: and fork:, each listing a branch’s commits from oldest to newest. They share a common beginning (the merge base). Print merge base: b, then ahead 1: x (the fork’s commits after the base) and behind 2: c d (upstream’s), and a recommendation: up to date, sync with upstream (only behind), ready for a pull request (only ahead), or diverged: sync before opening a pull request (both). Print - for empty lists.
- Diverged
- Behind
- Up to date
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
License advisor bot
Write a tiny license advisor. Each input line answers three yes/no questions for a project: copyleft patents network - does the author want modified versions to stay open source? Do they want an explicit patent grant? Will it mostly run as a web service? Recommend:
- copyleft and network →
AGPL-3.0 - copyleft →
GPL-3.0 - patents →
Apache-2.0 - otherwise →
MIT
Print project 1: MIT, then a final line counting each license recommended, most common first, ties alphabetically: MIT x2, GPL-3.0 x1.
- Four projects
- Copyleft fans
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Questions about this lesson
Stuck? Ask. Figured something out? Share it. Explaining is one of the best ways to learn.
Loading posts…