Git clone vs. fork: local copy or server workflow?

Clone is a Git command that creates a local repository from another repository. A fork is usually a hosting-provider feature that creates a server-side repository under a different account or namespace. They solve different parts of a contribution workflow.

Clone when you can work in the source repository

git clone https://example.com/team/project.git
cd project
git remote -v

The source normally becomes origin. If you have permission to push branches there, a separate fork may be unnecessary.

Fork when you need an independent server-side copy

Create the fork through the hosting provider, then clone your fork. Add the original repository as upstream:

git clone https://example.com/you/project.git
cd project
git remote add upstream https://example.com/team/project.git
git remote -v

Fetch updates from upstream and integrate them according to the project’s policy:

git fetch upstream
git switch main
git merge --ff-only upstream/main

Push contribution branches to your fork (origin) and open a pull or merge request toward the original repository.

A copied folder is neither

Copying files does not preserve Git metadata unless the hidden .git directory is included, and duplicating that metadata without understanding its remotes can be confusing. Prefer a real clone for a working copy.

Fork permissions and visibility depend on the hosting provider. Git itself has no fork command. If authentication is the main choice, compare HTTPS vs. SSH for Git.