If you’re new to Git, you’ve probably heard the terms “fork” and “clone” thrown around like they’re interchangeable. But while both create copies of repositories, they serve very different purposes—especially when collaborating on open-source projects. So let’s break it down.
Cloning: The Git Command You Actually Type
Cloning is a native Git operation. When you run git clone <repository-url>, Git downloads a full copy of the repository to your local machine. Perfect when you want to explore or work on a project on your own computer.
But if you clone a public open-source project and make changes locally, you’ll quickly run into a problem: you can’t push your changes back to the original repository unless you have write access (which you likely don’t).
That’s where forking comes in.
Forking: A Workflow for Collaboration
Interestingly, "fork" isn’t even a Git command. It’s a hosting service feature provided by platforms like GitHub and GitLab. When you fork a repository, you create a server-side clone of it under your own account. You now have full control over this new copy—you can modify it, push to it, and even delete it.
The fork retains a connection to the original repository, known as the upstream. This relationship enables a powerful workflow: you can make changes in your fork, then open a pull request asking the original maintainers to review and merge your contributions.
This model is essential for open-source collaboration. It keeps the original repository protected, while still allowing thousands of developers to contribute.
Fork & Clone Visually Explained
How Fork and Clone Work Together
The typical flow:
Fork the original repository via GitHub or GitLab.
Clone your fork to your local machine.
Create a feature branch, make changes, and push the branch to your fork.
Open a pull request to the original repository (the upstream) to propose your changes.
If accepted, your contribution becomes part of the upstream project.
When Should You Use Fork vs Clone?
Just exploring or learning? A simple clone is enough.
Want to contribute to a public project you don’t own? Fork it first, then clone your fork.
Working within a private team repo? You probably don’t need to fork—just clone and collaborate using branches.
I attended the University of Maryland where I graduated with a bachelor's degree in Computer Science. Since then, I’ve gathered experience in the tech industry, both as a software engineer and people manager. My longest stint was 7 years at Amazon where I… read more.
