The key difference between Git clone and fork comes down to how much control and independence you want over the codebase once you've copied it.
Any public Git repository can be forked or cloned. A fork creates a completely independent copy of Git repository. In contrast to a fork, a Git clone creates a linked copy that will continue to synchronize with the target repository.
Git clone vs. fork
When a Git repository is cloned, the target repository remains shared amongst all of the developers who had previously contributed to it. Other developers who had previously contributed to that codebase will continue to push their changes and pull updates from the cloned repository. Any developer who clones a repository can synchronize their copy of the codebase with any updates made by fellow developers.
In contrast to a clone, a Git fork operation will create a completely new copy of the target repository. The developer who performs the fork will have complete control over the newly copied codebase. Developers who contributed to the Git repository that was forked will have no knowledge of the newly forked repo. Previous contributors will have no means with which they can contribute to or synchronize with the Git fork unless the developer who performed the fork operation provides access to them.
How to choose between Git fork and clone
A programmer who joins a software development team and plans to contribute back to the codebase will typically clone the target repository. When changes or updates are made, either by the developer or by other members of the team, any clone can be easily synchronized with a git push or a git pull.
A developer who wants to set up a new, separate and isolated project that is based on a publicly accessible Git repo should perform a fork.
Some famous examples of Git forks include:
The Git fork and clone workflow
When a repository is forked, developers who plan to work with the new codebase will still need to perform a git clone operation on the forked repository. You'll still need to run push and pull operations to synchronize local changes with the forked repo, as shown in the diagram below. However, changes and updates to the forked repository will be isolated to the fork and will not be reflected in the original repo.
The choice between a Git fork or clone comes down to how much control you need over the codebase, along with how collaboratively you want to work with other contributors. Be sure to choose wisely to ensure your distributed and collaborative development workflows runs smoothly.
Dig Deeper on Java Development Tools
Related Q&A from Cameron McKenzie
What is the difference between a variable written in kebab case vs. camel case? Here we'll show you how these naming conventions differ and when to ... Continue Reading
Sun Microsystems architects designed Java to be cross-platform. But why? Here we look at not only why Java works across platforms, but also how it ... Continue Reading
The use of white space is what separates camel case and snake case. Camel case has none, while snake case uses underscores. Let's review some ... Continue Reading