Getty Images/iStockphoto

Git fork vs. clone: What's the difference?

Both Git fork and clone create copies of a repository, but they offer drastically different levels of access, isolation and control over the target repo.

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:

  • Jenkins, which is a fork of Hudson
  • Fire OS for Kindle Fire, which is a fork of Android
  • LibreOffice, which is a fork of OpenOffice
  • Ubuntu, which is a fork of Debian
  • MariaDB, from MySQL

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.

Git clone vs. fork
Developers who work on a shared codebase will want to clone a repository, while a fork will create an independent codebase that is completely separate from the original, forked 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 Development tools for continuous software delivery