Introduction

If you want to know whether origin has new commits, the safe approach is to fetch the remote refs and compare them with your local branch. That lets you inspect incoming changes without merging, rebasing, or changing your working tree. In Git terms, checking is a fetch-and-compare task, not a pull task.

Fetch First

Start by updating your remote-tracking references.

git fetch origin

This downloads new objects and updates refs such as origin/main, but it does not merge anything into your current branch.

That separation matters. You get an up-to-date view of the remote without modifying your branch history.

Use git status -sb for a Quick Answer

After fetching, git status -sb gives a fast ahead-or-behind summary.

git status -sb

Typical output:

## main...origin/main [behind 3]

That means your current branch is three commits behind the corresponding remote-tracking branch.

See Which Commits Exist on the Remote

To inspect the commits that are on origin/main but not on your current branch, use:

git log HEAD..origin/main --oneline

That answers the practical question, "What has changed remotely that I have not integrated yet?"

To inspect the opposite direction:

git log origin/main..HEAD --oneline

That shows commits you have locally that the remote does not yet have.

Check the Actual File Differences

If commit messages are not enough, inspect the content diff.

git diff HEAD..origin/main

For a shorter overview, use:

git diff --stat HEAD..origin/main

This is often the most useful pre-pull check because it tells you which files changed and by how much.

Compare a Different Remote Branch

You are not limited to the current branch. Once you fetch, any remote-tracking branch can be examined.

git fetch origin
git log origin/feature-x --oneline -5
git diff HEAD..origin/feature-x --stat

That is handy when you want to inspect a teammate's branch without checking it out.

Get Ahead-Behind Counts Programmatically

If you want exact numbers for automation or a concise terminal check, rev-list is useful.

git rev-list --left-right --count HEAD...origin/main

The command prints two numbers: how many commits you are ahead and how many you are behind.

This is often easier to consume in scripts than parsing human-oriented git status output.

Why git pull Is the Wrong Inspection Tool

Many developers run git pull just to see whether anything changed. That works, but it also starts integrating those changes according to local pull settings.

A better sequence is:

1. git fetch origin
2. inspect git status, git log, or git diff
3. decide whether to merge, rebase, or simply stay where you are

That keeps inspection separate from state changes.

Clean Up Stale Remote Branches

If you also want to know whether branches disappeared from the remote, fetch with pruning:

git fetch --prune origin

This removes local remote-tracking refs for branches that no longer exist on the server.

Common Pitfalls

• Using git pull when the goal was only to inspect remote changes.
• Comparing against origin/main before running git fetch, which leaves you looking at stale information.
• Checking the wrong remote branch and drawing the wrong conclusion about what changed.
• Assuming origin/main updates automatically without fetch or pull.
• Looking only at file diffs and forgetting to check whether you also have local commits not yet pushed.

Summary

• Use git fetch origin to update your view of the remote safely.
• 'git status -sb gives a quick ahead-or-behind summary.'
• 'git log HEAD..origin/main shows remote commits you do not have yet.'
• 'git diff HEAD..origin/main shows the content changes without integrating them.'
• Fetch first, inspect second, and pull only after you decide how to integrate the remote work.