Push & pull problemsAlways fixable

Update your fork with the latest changes from the original repo

How do I sync my fork with the upstream repository?

Short answer

Add the original repository as a remote called upstream, fetch it, then merge or rebase upstream/main into your main and push. GitHub's 'Sync fork' button does the same thing, but doing it locally gives you control when your fork has diverged.

quick fix
git fetch upstream
git switch main
git merge upstream/main
git push

Pull in the original project's latest commits and publish them to your fork

Does this match your situation?

  • Your fork is 'X commits behind' the original repository.
  • You need recent upstream changes before opening a pull request.
  • Your pull request shows conflicts against the upstream branch.

Step-by-step fix

  1. Register the original repository as upstream

    A fork's origin points at your copy; the original project isn't connected at all until you add it. This only needs doing once per clone.

    step 1
    git remote -v
git remote add upstream https://github.com/ORIGINAL/REPO.git
git remote -v      # you should now see origin and upstream

  2. Fetch what upstream has

    Fetching downloads their commits into upstream/* tracking branches without touching yours, so you can inspect before integrating.

    step 2
    git fetch upstream
git log --oneline main..upstream/main    # what you're missing

  3. Bring the changes into your main branch

    Merge if your main has no commits of its own — it'll simply fast-forward. Rebase if you did commit directly to main and want a clean line.

    step 3
    git switch main
git merge upstream/main

# or, to keep history linear:
git rebase upstream/main

  4. Push the update to your fork

    Your fork on the server is a separate repository, so it doesn't update until you push.

    step 4
    git push origin main

    If you rebased and main was already pushed, you'll need git push --force-with-lease.

  5. Update your feature branch too

    Rebasing your feature work onto the refreshed main resolves conflicts before the maintainer ever sees them.

    step 5
    git switch feature/my-work
git rebase main
git push --force-with-lease

Why this works

A fork is a full, independent copy on the server — GitHub doesn't keep it in step with the original automatically. Locally, origin and upstream are just two named URLs pointing at two repositories that happen to share history. Because they share ancestry, Git can fast-forward or rebase between them cleanly. Keeping your main branch a pure mirror of upstream, and doing all your work on feature branches, makes this a one-command operation forever.

How to stop it happening again

  • Never commit directly to main in a fork — keep it a clean mirror of upstream.
  • Sync before starting any new branch so you begin from current code.
  • Add the upstream remote immediately after cloning a fork, before you forget.

Commands used in this guide

git remote

Manage the named URLs your repository syncs with.

git fetch

Download new commits from the remote without changing any of your files.

git merge

Combine another branch's history into the current one.

git rebase

Replay your commits on top of another branch to produce a straight, linear history.

git push

Upload your commits to the remote repository.

Still stuck?

Search the full command reference and every other rescue guide — there are 56 of them, covering everything from detached HEAD to force-push disasters.

Browse all guides →

Frequently asked questions

How do I sync a forked repository with the original?

Add the original as a remote named upstream, run git fetch upstream, switch to main, then git merge upstream/main and push to your fork. GitHub's web UI has a 'Sync fork' button that does the equivalent for simple cases.

Should I merge or rebase when syncing a fork?

Merge if your main is a clean mirror with no commits of its own — it just fast-forwards. Rebase if you have local commits on main and want linear history, but be aware it rewrites those commits and needs a force-push afterwards.

My fork has diverged and merging creates conflicts. What now?

If your main should be a pure mirror, the cleanest fix is to reset it to upstream: git switch main, git reset --hard upstream/main, git push --force-with-lease. Move any real work onto a feature branch first, otherwise you'll lose it.

Related rescue guides

Always fixable

How do I change the remote URL of a Git repository?

git remote set-url origin <new-url> repoints an existing remote. It's a purely local change — nothing on either server is touched — so it's the safe way to switch between HTTPS and SSH, move to a new host, or fix a URL after renaming the repository.

Read the fix →Always fixable

My push was rejected — 'Updates were rejected because the remote contains work that you do not have'. What now?

Someone pushed commits you don't have yet, so your push would erase them. Git is protecting you. Fetch and integrate their work first with git pull --rebase, then push again. Never reach for --force here unless you genuinely intend to delete what's on the server.

Read the fix →Always fixable

How do I undo a git pull?

A pull is a fetch plus a merge or rebase, so undoing it means moving your branch back to where it was. git reset --hard ORIG_HEAD does exactly that, because Git saves your pre-pull position there automatically.

Read the fix →Always fixable

git pull says I need to specify how to reconcile divergent branches — what do I choose?

Git 2.27+ refuses to guess whether you want a merge or a rebase when both sides have new commits. Pick one — git config --global pull.rebase true gives you clean linear history and is the best default for most people.

Read the fix →
← All Git Rescue guides