Explore fork workflow
The forking workflow is fundamentally different than other popular Git workflows.
Instead of using a single server-side repository to act as the "central" codebase, it gives every developer their server-side repository.
It means that each contributor has two Git repositories:
- A private local.
- A public server-side.
The forking workflow is most often seen in public open-source projects.
The main advantage of the forking workflow is that contributions can be integrated without the need for everybody to push to a single central repository.
Developers push to their server-side repositories, and only the project maintainer can push to the official repository.
It allows the maintainer to accept commits from any developer without giving them written access to the official codebase.
The forking workflow typically will be intended for merging into the original project maintainer's repository.
The result is a distributed workflow that provides you a flexible way for large, organic teams (including untrusted third parties) to collaborate securely.
This also makes it an ideal workflow for open-source projects.
How it works
As in the other Git workflows, the forking workflow begins with an official public repository stored on a server.
But when a new developer wants to start working on the project, they don't directly clone the official repository.
Instead, they fork the official repository to create a copy of it on the server.
This new copy serves as their personal public repository—no other developers can push to it, but they can pull changes from it (we'll see why this is necessary in a moment).
After they've created their server-side copy, the developer does a git clone to get a copy of it onto their local machine.
It serves as their private development environment, just like in the other workflows.
When they're ready to publish a local commit, they push the commit to their public repository—not the official one.
Then, they file a pull request with the main repository, which lets the project maintainer know that an update is ready to be integrated.
The pull request also serves as a convenient discussion thread if there are issues with the contributed code.
The following is a step-by-step example of this workflow:
- A developer 'forks' an 'official' server-side repository. It creates their server-side copy.
- The new server-side copy is cloned to their local system.
- A Git remote path for the 'official' repository is added to the local clone.
- A new local feature branch is created.
- The developer makes changes to the new branch.
- New commits are created for the changes.
- The branch gets pushed to the developer's server-side copy.
- The developer opens a pull request from the new branch to the 'official' repository.
- The pull request gets approved for merge and is merged into the original server-side repository.
To integrate the feature into the official codebase:
- The maintainer pulls the contributor's changes into their local repository.
- Checks to make sure it doesn't break the project.
- Merges it into their local main branch.
- Pushes the main branch to the official repository on the server.
The contribution is now part of the project, and other developers should pull from the official repository to synchronize their local repositories.
It's essential to understand that the notion of an "official" repository in the forking workflow is merely a convention.
The only thing that makes the official repository, so official is that it's the repository of the project maintainer.
Forking vs. cloning
It's essential to note that "forked" repositories and "forking" aren't special operations.
Forked repositories are created using the standard git clone command. Forked repositories are generally "server-side clones" managed and hosted by a Git service provider such as Azure Repos.
There's no unique Git command to create forked repositories.
A clone operation is essentially a copy of a repository and its history.