What is the difference between clone, fetch, pull and push?

Question

Accepted Answer

These four commands move data between your **local** repository and **remote** repositories, but they do different things. Understanding the distinctions — especially **fetch vs pull** — is important for working with remotes correctly.

## clone — copy a repository (once)

```bash
git clone <url>
# → creates a LOCAL copy of an entire remote repository (all history + branches)
# → sets up "origin" pointing to the remote; done ONCE to start working on a project
```

`clone` downloads a complete copy of a remote repository to start working — done once per project.

## fetch — download remote changes (don't merge)

```bash
git fetch origin
# → downloads new commits/branches from the remote into remote-tracking branches
#   (origin/main, etc.) but does NOT change your working files or current branch
# → SAFE: lets you SEE what's new before integrating it
git log origin/main            # inspect the fetched changes
```

`fetch` downloads remote changes **without merging** them — your working files are untouched, letting you inspect before integrating.

## pull — fetch AND merge

```bash
git pull origin main
# → fetch + merge: downloads remote changes AND merges them into your current branch
# → updates your working files (may cause merge conflicts)
# pull = fetch + merge (or fetch + rebase with --rebase)
```

`pull` does `fetch` then immediately **merges** the changes into your current branch — a convenient combination, but it changes your files (and can conflict).

## push — upload your commits

```bash
git push origin main
# → uploads YOUR local commits to the remote (the opposite direction of pull)
# → shares your work; fails if the remote has changes you don't have (pull first)
```

```text
clone → copy a repo (start)      fetch → download (no merge)
pull  → fetch + merge (update)   push  → upload your commits (share)
```

## Why it matters

Understanding the difference between clone, fetch, pull, and push is important for **working with remote repositories correctly**, so it's essential practical knowledge — and these are commonly confused, especially fetch vs pull.

Each serves a distinct purpose: **`clone`** copies an entire remote repository to start working (done once), **`fetch`** downloads remote changes **without merging** (safely letting you inspect what's new before integrating), **`pull`** does fetch **and merges** (conveniently updating your branch but changing your files and potentially causing conflicts), and **`push`** uploads your commits to share your work.

The **fetch vs pull distinction is particularly important and commonly misunderstood**: `fetch` is non-destructive (downloads without touching your work, so you can review changes first), while `pull` immediately integrates changes into your working branch — understanding this lets you choose the safer `fetch`-then-inspect approach when you want control, rather than always pulling blindly.

Knowing that **`push` fails if the remote has changes you don't have** (requiring you to pull first) explains a common situation.

Understanding the directions (clone/fetch/pull bring changes *in*; push sends changes *out*) clarifies the data flow between local and remote.

Since working with remotes is fundamental to collaboration and these four commands are how data moves between local and remote repositories, and since confusing them (especially fetch vs pull) leads to mistakes or unexpected merges, understanding the difference between clone, fetch, pull, and push is essential, frequently-applied Git knowledge for collaborative development — clarifying the core remote operations every developer uses and resolving a commonly-confused distinction (fetch vs pull) that affects how safely you integrate others' changes.