Introduction

Git does not provide a single safe command that pulls and pushes every branch the way many people expect. git pull only updates the current checked-out branch, and git push only sends refs you explicitly select or that match your push configuration, so full multi-branch sync has to be handled deliberately.

Understand What Git Can and Cannot Do

The first step is separating three different operations:

• 'git fetch downloads remote refs and objects.'
• 'git pull fetches, then merges or rebases the current branch.'
• 'git push updates remote refs from local refs.'

If your goal is "see every remote branch and update my remote view," use fetch:

git remote -v
git fetch --all --prune
git branch -r

--prune removes stale remote-tracking refs, which keeps branch lists from drifting over time.

Create or Verify Tracking Branches

Fetching does not automatically create a local branch for every remote branch. If you want local branches that follow remote ones, create them explicitly:

git switch --track origin/feature/login
git switch --track origin/release/2026.03

To inspect existing upstream relationships:

git branch -vv

If a local branch exists but is not tracking the right remote branch, fix it:

git branch --set-upstream-to=origin/feature/login feature/login

That upstream metadata matters because it controls what plain git pull and many push operations actually target.

Push All Local Branches Only When You Mean It

If you really do want to publish every local branch to origin, Git supports that:

git push origin --all
git push origin --tags

This is useful in mirror-like environments or personal backup remotes, but it is risky in a team repository where you may have scratch branches that should stay private. For normal collaboration, pushing only the branches you actively maintain is usually safer.

If you need a true mirror of all refs, there is also:

git push --mirror origin

That is much more aggressive because it mirrors branch and tag deletions as well. It is appropriate for repository mirroring, not everyday development.

Use a Safe Multi-Branch Workflow

A practical routine for many repositories is:

1. Fetch everything with prune.
2. Inspect which local branches track which remotes.
3. Update important branches one by one.
4. Push only the branches that should be published.
5. Push tags separately when release metadata matters.

Helpful inspection commands:

git for-each-ref --format='%(refname:short) -> %(upstream:short)' refs/heads
git log --oneline --decorate --graph --all -n 20

These commands make it obvious when a branch has no upstream, is ahead of remote, or points somewhere unexpected.

Configure Conservative Defaults

Some global settings make multi-branch work more predictable:

git config --global fetch.prune true
git config --global push.default simple
git config --global pull.rebase false

push.default simple is intentionally conservative. It pushes the current branch to its upstream instead of trying to guess broader intent.

Common Pitfalls

• Expecting git pull on one branch to refresh every other local branch.
• Running git push origin --all without checking for temporary or experimental branches.
• Forgetting to configure upstream tracking, which makes pull and push behavior inconsistent.
• Using --mirror on a normal collaboration remote and unintentionally deleting refs.
• Treating tags as automatic when your workflow actually requires a separate git push --tags.

Summary

• Use git fetch --all --prune to refresh your view of all remote branches.
• Remember that git pull only updates the current branch.
• Create and verify tracking branches explicitly with git switch --track and git branch -vv.
• Use git push origin --all only when publishing every local branch is genuinely intended.
• Prefer conservative Git defaults over broad automatic sync behavior.