How does GitHub's fork and clone model work for open source contributions?

Think of forking like photocopying a library book. The original book (upstream repository) stays on the library shelf untouched. Your photocopy (fork) is yours to annotate, highlight, and modify however you want. If you discover an error in the book and write a correction in your copy, you can submit a note to the librarian (pull request) suggesting they update the original. Cloning is different. It is like checking out the book to read at home. You get a local copy to work with, but it is still the same book, not a separate one.

Forking is a GitHub-specific operation (not a Git feature) that creates a server-side copy of a repository under your account, preserving the connection to the original. Your fork shares the same Git objects initially, so GitHub does not actually duplicate all the data. It creates a copy-on-write relationship. When you push changes to your fork, those changes exist only in your copy. The upstream repository is completely unaffected. Cloning, by contrast, is a standard Git operation that downloads a repository (either the original or your fork) to your local machine, creating a working directory where you can edit files, create branches, and make commits.

The standard open source contribution workflow connects these operations. First, you fork the upstream repository on GitHub, creating your-username/project. Then you clone your fork locally with git clone. You add the original repository as a second remote called 'upstream' so you can pull in new changes from the original project. You create a feature branch, make your changes, commit, and push to your fork (origin). Finally, you open a pull request from your fork's branch to the upstream repository's main branch. The upstream maintainers review your PR, request changes if needed, and eventually merge it.

In the open source ecosystem, forking enables a trust model where anyone can contribute without being given write access to the repository. Projects like kubernetes/kubernetes, facebook/react, and microsoft/vscode receive thousands of contributions through forks. The fork model also protects the upstream repository: if someone pushes malicious code to their fork, it does not affect the original. Maintainers review every change through the PR process. For organizations, forks are sometimes used internally to let teams customize a shared library without polluting the original repository. GitHub also supports keeping forks in sync with a 'Sync fork' button that fetches upstream changes into your fork's default branch.

A common gotcha is forgetting to keep your fork in sync with upstream. If the upstream repository receives many commits while you are working on your fork, your branch may have merge conflicts when you open a PR. Regularly fetch from upstream and rebase your feature branch. Another mistake is cloning the upstream repository directly instead of your fork, then wondering why you cannot push. You can only push to repositories where you have write access, which is your fork, not the upstream. Always clone your fork and add upstream as a separate remote.