Fetch, Pull & Push

Three operations, one diagram

Every exchange with a remote is one of three things: download, download-and-merge, or upload. Git separates them into three commands precisely so you can pick the level of automation you want. The picture below is worth more than the prose; once it clicks, the commands stop blurring together.

The middle column is the bit most beginners miss. Remote-tracking refs like origin/main live in your local repository. They are your local cached view of what the remote looked like the last time you talked to it. git fetch only updates this middle column. Your own branches and your working tree are untouched.

git fetch: pure download

Fetch is the safe command. You can run it any time, on any branch, in any state. It only reads from the remote and writes to refs Git considers yours-but-about-them. Nothing about your local work changes.

git fetch                  # fetch from the default remote (origin)
git fetch origin           # explicit
git fetch --all            # fetch from every configured remote
git fetch --prune          # also delete origin/* refs whose branches were deleted upstream
git fetch origin main      # fetch only one branch

After fetching, you can inspect what arrived before changing anything:

git log --oneline HEAD..origin/main    # commits on the remote that you do not have yet
git log --oneline origin/main..HEAD    # commits on you that the remote does not have yet
git diff HEAD origin/main              # the actual content difference

This is why fetch is the foundation of everything else. Pull is built from it, and a careful push is preceded by it. If you remember nothing else from this page, remember: fetch first, then decide.

git pull: fetch plus integrate

Pull is a convenience. It saves typing two commands. The trade-off is that it does change your branch — it can create a merge commit, replay your work on top of theirs, or stop midway with conflicts. You should know which of those is going to happen before you run it.

git pull                   # fetch + merge (or fetch + rebase if pull.rebase is true)
git pull --rebase          # fetch + rebase, this run only
git pull --ff-only         # fetch + only fast-forward; fail if branches have diverged

The default merge behaviour creates a merge commit any time your branch and the remote both have new work. Many teams find these "pull merges" noisy because they record the act of synchronising rather than any real design decision. The rebase variant rewrites your local commits onto the new tip, leaving a linear history at the cost of changing commit IDs. (Rebase has its own rules — covered in Rebasing.)

git config --global pull.rebase true
# or, to preserve any local merge commits you actually meant to make:
git config --global pull.rebase merges

git push: publish your commits

Push is the only command in this trio that writes to someone else's repository. That asymmetry is why Git is conservative about it: a careless push can erase work that other people have already based their own commits on.

git push                       # push the current branch to its configured upstream
git push origin main           # explicit: push local main to origin's main
git push origin feature:main   # push local feature to a remote branch named main (rare)

Fast-forward, the normal case

A push is a fast-forward when the remote's current tip is an ancestor of the commit you are pushing. Picture the remote sitting on commit C and your local branch sitting on C → D → E. Git can simply move the remote's branch pointer from C to E — no history is rewritten, no commits are lost. This is what almost every push looks like on a personal feature branch nobody else has touched.

Comparing fetch, pull, and push

Non-fast-forward rejection

If someone else pushed to main after you last fetched, the remote tip is no longer an ancestor of your tip. Git refuses the push:

$ git push origin main
To github.com:org/repo.git
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'github.com:org/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.

The fix is the workflow Git is trying to teach you: fetch, look at what arrived, integrate it, then push.

git fetch origin
git log --oneline HEAD..origin/main   # what did they add?
git rebase origin/main                # or: git merge origin/main
git push origin main

This is not Git being difficult. The rejection exists so that two people pushing at the same time cannot silently overwrite each other. Without it, the last writer wins and the loser's commits become unreachable on the remote.

Force pushing: the lease rule

Sometimes you genuinely need to overwrite a remote branch — you rebased a feature branch, amended its last commit, or squashed it for review. The remote and your local now disagree about history that is "yours" anyway. For that, Git has two escape hatches, and the difference between them matters.

git fetch origin
git rebase origin/main
git push --force-with-lease origin feature

Tags and new branches

Pushing tags

Tags are not pushed by default. A normal git push sends commits and updates the branch ref; tags ride along only if you ask:

git push origin v1.2.0    # push one specific tag
git push origin --tags    # push every local tag the remote does not have
git push --follow-tags    # push branch + annotated tags that point at pushed commits

--follow-tags is often the sweet spot for release workflows: it pushes the branch plus any annotated tags relevant to the commits being pushed, without dumping every stray local tag you ever made.

Pushing a new branch the first time

A branch that exists only locally has no upstream — Git does not know which remote branch should receive it. The first push needs to set that up:

git switch -c feature/payments
# ... commits ...
git push -u origin feature/payments    # -u = --set-upstream

From then on, plain git push and plain git pull work on this branch with no arguments. The -u flag records origin/feature/payments as the upstream of your local feature/payments, which is also what enables git status to tell you "your branch is ahead by 2 commits."

The fetch-first habit

Plenty of trouble disappears when you make one small change to your routine: fetch before you act. Not pull — fetch. The two commands you would otherwise run blind become two commands you run with eyes open.

git fetch origin
git status                            # am I ahead, behind, or both?
git log --oneline HEAD..origin/main   # what did they add?
# now choose, deliberately:
git merge origin/main                 # preserve their commits as-is
# or
git rebase origin/main                # replay my commits on top of theirs
# then publish
git push

The same loop covers the awkward cases: a conflict you would rather face on a clean working tree, a colleague who force-pushed and rewrote a branch you were tracking, a tag you had not noticed. Fetch is cheap. Run it often.

Common pitfalls

Worked examples

git fetch origin
git log --oneline --graph HEAD..origin/main
git diff --stat HEAD origin/main

git fetch origin
git log --oneline HEAD..origin/main      # what new work landed?
git rebase origin/main                   # replay your commits on top
# resolve any conflicts, then:
git rebase --continue
git push origin main

git fetch origin                                    # know exactly what the remote has
git rebase origin/main                              # rewrite local feature on top of main
git push --force-with-lease origin feature/payments

git switch -c release/1.4
# ... commits ...
git tag -a v1.4.0 -m "Release 1.4.0"

git push -u origin release/1.4   # publishes the branch and sets upstream
git push origin v1.4.0           # tags are not pushed automatically