Forking a GitHub repository is surprisingly not about copying code, but about creating your own independent workspace that mirrors the original project.
Let’s see this in action. Imagine you want to contribute to octocat/Spoon-Knife, a popular example repo.
First, you navigate to the octocat/Spoon-Knife page on GitHub. You’ll see a prominent "Fork" button. Clicking it initiates the process. GitHub then creates a complete copy of the octocat/Spoon-Knife repository under your own GitHub username, say your-username/Spoon-Knife. This is your copy, completely separate from the original. You can make any changes you want here without affecting the original project.
Now, you want to make a change, perhaps add a new line to the README.md file. You clone your forked repository to your local machine:
git clone https://github.com/your-username/Spoon-Knife.git
cd Spoon-Knife
You make your edits locally. For instance, you add "This is my awesome contribution!" to the README.md. Then, you commit these changes:
git add README.md
git commit -m "Add my awesome contribution"
After committing, you push these changes back to your fork on GitHub:
git push origin main
Now, on your your-username/Spoon-Knife page on GitHub, you’ll see a prompt suggesting you create a "Pull Request" to send your changes back to octocat/Spoon-Knife. Clicking this takes you to the Pull Request creation page.
Here’s where the magic happens. You’re not just "sending code"; you’re proposing a change. You select your fork (your-username/Spoon-Knife) as the "head repository" and octocat/Spoon-Knife as the "base repository." You also specify the branch in your fork that contains your changes (e.g., main) and the branch in the original repository you want to merge into (typically main).
The Pull Request (PR) is an invitation to the maintainers of octocat/Spoon-Knife to review your proposed changes. They can see exactly what you’ve changed, line by line. They can comment on your changes, ask for modifications, or even suggest alternative approaches. This review process is crucial for maintaining code quality and ensuring new contributions align with the project’s goals.
Once the maintainers are happy with your changes, they can "merge" your Pull Request. This action takes the commits from your branch in your fork and applies them to the main branch of the octocat/Spoon-Knife repository. Your contribution is now part of the original project.
The underlying mechanism of a fork is that it establishes a completely independent lineage of code. When you create a PR, you’re essentially highlighting a specific set of commits on your lineage that you believe should be integrated into another lineage. The merge operation is the act of reconciling these two lineages by applying the commits from one to the other.
The most surprising aspect for newcomers is that the "fork" itself doesn’t actually copy any code in the sense of creating a new, identical repository on GitHub’s servers. Instead, it creates a new reference to the original repository’s commit history, allowing you to build your own branch of that history. When you clone, you get the actual files.
When you create a Pull Request, GitHub presents a diff between the target branch of the base repository and the source branch of your fork. This diff is what the maintainers review. The merge operation then applies the commits that created that diff onto the base branch.
After your Pull Request is merged, your local Spoon-Knife repository (the one you cloned from your fork) is now out of sync with the original octocat/Spoon-Knife repository. To get the latest changes from the original project, you’ll need to add the original repository as a remote and pull from it.
git remote add upstream https://github.com/octocat/Spoon-Knife.git
git fetch upstream
git merge upstream/main
This process of forking, branching, committing, pushing, creating a Pull Request, and merging is the fundamental workflow for contributing to most open-source projects hosted on GitHub. The next step is understanding how to resolve merge conflicts when your changes overlap with changes made by others.