Forking and Cloning
Cloning is a core Git operation: git clone <url> downloads a repository's entire history — every commit, branch, and tag reachable from it — and sets up a working directory with the default branch checked out, plus an origin remote pointing back at the source. Forking, by contrast, is not a Git feature at all; it's a hosting-platform feature (GitHub, GitLab, Bitbucket) that creates a full server-side copy of a repository under your own account, complete with its own URL, issue tracker, and settings, independent of the original. The two are usually combined: fork a repository on GitHub to get your own copy, then clone your fork to your machine to actually work on it locally.
Cricket analogy: Like copying an entire team's full match archive and stats history onto your laptop with a live link back to the board's servers (cloning), versus a rival league creating its own independent franchise copy of a team's entire roster under new ownership (forking) — scouts often do both, forking a franchise then studying it locally.
Why Forking Exists
Most open-source (and many internal) repositories restrict direct push access to a small set of maintainers. Forking solves the 'how does an outside contributor propose changes?' problem: since you can't push directly to the original repository, you push to your own fork instead, then open a pull request asking the original project's maintainers to pull your changes in. This keeps the original repository's branch protection and access control intact while still allowing anyone to propose contributions. Inside a single organization with shared write access, teams often skip forking entirely and just use feature branches directly on the shared repository, since everyone already has push rights.
Cricket analogy: Like an outside player who isn't contracted to a franchise proving himself in the domestic circuit and submitting his performance for selectors to pick up, rather than walking straight into the national squad — but a player already on staff, like a contracted all-rounder, just gets picked directly for the next match.
Clone Depth, Protocols, and Options
By default, git clone fetches the complete history, which can be slow for repositories with years of large commits. git clone --depth 1 performs a 'shallow clone', fetching only the most recent commit's snapshot — useful for CI pipelines or quick one-off builds that don't need history, though it limits some operations like git log on older commits or certain rebases until you git fetch --unshallow. Clone URLs come in a few flavors: HTTPS (https://github.com/org/repo.git, usually paired with a personal access token or credential helper) and SSH ([email protected]:org/repo.git, using an SSH key pair) are the two most common; SSH avoids re-entering credentials on every push once your key is set up.
Cricket analogy: Like requesting only the highlights reel of a team's most recent match instead of the full decade-long archive when you just need to scout current form quickly (shallow clone) — fine for a quick assessment, but you'd need the full archive back if you wanted to study historical head-to-head stats.
# Standard full clone via SSH
git clone git@github.com:acme/webapp.git
# Clone into a specific local directory name
git clone https://github.com/acme/webapp.git my-webapp-copy
# Shallow clone for CI speed (only the latest commit's snapshot)
git clone --depth 1 https://github.com/acme/webapp.git
# Typical fork + clone contribution flow
# 1. Fork acme/webapp to yourname/webapp on GitHub (via the web UI or `gh repo fork`)
gh repo fork acme/webapp --clone
# 2. Add the original repo as 'upstream' to stay in sync
git remote add upstream https://github.com/acme/webapp.git
# 3. Work on a feature branch, push to your fork (origin)
git checkout -b fix/broken-link
git push -u origin fix/broken-link
# Then open a pull request from yourname/webapp:fix/broken-link into acme/webapp:mainGitHub's own gh CLI can fork and clone in a single command — gh repo fork owner/repo --clone — and even sets upstream to the original repository automatically, saving the two manual steps of forking via the web UI and adding the upstream remote yourself.
A shallow clone (--depth 1) truncates history, which can break tools or workflows that assume full history is present — for example, git log, git blame on older lines, some CI 'changed since last release' scripts, or an interactive rebase reaching past the shallow boundary. If you hit missing-history errors after a shallow clone, run git fetch --unshallow to backfill the rest.
git clonedownloads a repository's full history and sets up anoriginremote — a core Git feature, not platform-specific.- Forking is a hosting-platform feature (not Git itself) that creates an independent server-side copy under your own account.
- The typical open-source contribution flow is: fork on the platform, clone your fork locally, push branches to your fork, then open a pull request into the original.
--depth 1shallow clones fetch only the latest snapshot, trading full history for speed — useful in CI, riskier for full development work.- HTTPS and SSH are the two common clone protocols; SSH avoids repeated credential prompts once a key is configured.
git fetch --unshallowbackfills a shallow clone's missing history if a tool or workflow later needs it.
Practice what you learned
1. What is the key distinction between forking and cloning?
2. Why do open-source contributors typically fork a repository before contributing?
3. What does `git clone --depth 1` produce?
4. How can you obtain full history after making a shallow clone, if a later task requires it?
5. In the typical fork-based workflow, where do you push your feature branch before opening a pull request?
Was this page helpful?
You May Also Like
Remotes Explained
A remote is a named reference to another copy of a repository, usually hosted elsewhere, that Git uses to synchronize commits, branches, and tags between machines.
Pull Requests and Code Review
How pull requests turn a branch into a reviewable, discussable proposal for merging code, and the practices that make code review effective rather than a rubber stamp.
Tracking Branches
A tracking branch is a local branch configured with a direct relationship to a remote branch, enabling short commands like plain `git push` or `git pull` and clear ahead/behind status.
Push, Pull, and Fetch
Push, pull, and fetch are the three commands that move commits between your local repository and a remote — understanding exactly what each does (and doesn't do) prevents most everyday Git confusion.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics