Git Fork

Forking creates your own copy of someone else's repository on GitHub so you can experiment freely and propose changes back through a pull request.

What Forking Actually Does

A fork is a full copy of a repository under your own GitHub account, created with a click of the Fork button on the repository's page. Unlike cloning, forking happens on GitHub's servers, not your machine, and it preserves a link back to the original repository, called the upstream. This link is what lets GitHub offer to open a pull request comparing your fork against the original project.

Forking is the standard workflow for contributing to projects you don't have write access to. Instead of pushing directly to someone else's repository, you push to your fork, then ask the maintainers to review and merge your changes.

Cloning Your Fork

After forking on GitHub's website, clone your fork — not the original repository — to your local machine. This gives you a local copy where you can create branches, commit, and push freely.

Clone your fork

$ git clone git@github.com:yourusername/project.git
Cloning into 'project'...
remote: Enumerating objects: 214, done.
remote: Total 214 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (214/214), 58.21 KiB, done.

Setting Up the Upstream Remote

Your clone already has a remote named origin pointing at your fork. Add a second remote, conventionally named upstream, pointing at the original repository. This lets you pull in changes made by other contributors after you forked.

Add the upstream remote

$ git remote add upstream git@github.com:original-owner/project.git
$ git remote -v
origin    git@github.com:yourusername/project.git (fetch)
origin    git@github.com:yourusername/project.git (push)
upstream  git@github.com:original-owner/project.git (fetch)
upstream  git@github.com:original-owner/project.git (push)
Note: You can fetch from upstream but you typically won't have push access to it — that's expected and by design.

Keeping Your Fork in Sync

Forks don't update automatically when the original repository changes. Periodically fetch from upstream and merge or rebase its main branch into yours to avoid drifting far behind and hitting painful merge conflicts later.

Sync your local main with upstream

$ git fetch upstream
From github.com:original-owner/project
 * [new branch]      main       -> upstream/main
$ git checkout main
$ git merge upstream/main
Updating a1b2c3d..e4f5g6h
Fast-forward
 README.md | 12 +++++++-----

Contributing Back with a Pull Request

Once your fork is synced, create a feature branch, make your changes, and push the branch to your fork (origin). Then open a pull request on GitHub comparing your branch against the upstream project's main branch.

  • git checkout -b fix-typo-in-docs
  • Make your changes and commit them
  • git push -u origin fix-typo-in-docs
  • Open a pull request on GitHub from your branch into upstream's main
  • Respond to review comments by pushing more commits to the same branch

Fork vs Clone at a Glance

ActionWhere it happensWho can do it
ForkOn GitHub's serversAnyone with a GitHub account
CloneOn your local machineAnyone with read access
Push to originLocal machine to your forkYou, the fork owner
Push to upstreamLocal machine to original repoOnly maintainers with write access
Note: Delete feature branches from your fork after they're merged — GitHub even offers a one-click "Delete branch" button on a merged pull request, keeping your fork's branch list tidy.

Exercise: Git Fork

What is a "fork" in the context of platforms like GitHub?