Introduction

Before pushing, you usually want to answer two questions: which commits are not on the remote yet, and what file changes those commits contain. Git gives you direct commands for both, and using them is safer than pushing first and inspecting later.

See the Commits You Are About to Push

The most direct command is to compare your current branch with its upstream branch.

git log --oneline @{upstream}..HEAD

This shows commits reachable from your current HEAD that are not yet reachable from the upstream branch. If your local branch tracks origin/main, this is effectively “what I would push to origin/main right now.”

A slightly richer version includes authors and dates:

git log --stat --decorate @{upstream}..HEAD

That command is useful when you want both the commit list and a file-level summary.

If your branch does not have an upstream configured, set it or compare against the remote branch explicitly.

git log --oneline origin/main..HEAD

See the Actual Code Changes

A commit list is often not enough. To inspect the patch content, diff your branch against the upstream.

git diff @{upstream}..HEAD

This shows the combined patch that would be introduced by the commits you are about to push. If you want only filenames:

git diff --name-only @{upstream}..HEAD

If you want a quick size summary instead of full hunks:

git diff --stat @{upstream}..HEAD

In practice, many developers run both git log --oneline and git diff --stat before pushing. One shows the narrative of the change set, and the other shows its scope.

Verify the Upstream Branch First

These commands only make sense if you know where the branch is pushing. Check that with:

git branch -vv

This shows each local branch and its tracking branch. It also shows ahead or behind counts, which are a fast signal that you have commits waiting to push.

Example output might show:

* feature/login 1234abc [origin/feature/login: ahead 2] Add token refresh

That means two commits are ahead of the remote tracking branch.

Useful Review Combinations

A small pre-push checklist can be built from a few commands:

git status
git log --oneline @{upstream}..HEAD
git diff --stat @{upstream}..HEAD

git status matters because uncommitted changes are not part of the push. Developers sometimes inspect their working tree and assume those edits are included, but only committed changes are pushed.

If you want to confirm the exact commits that are unique to your branch, git cherry -v is also helpful.

git cherry -v

This lists commits in your local branch that are not in the upstream branch, prefixed with +.

Review Before a Force Push

If you are about to force push, review even more carefully. Compare your branch to the remote branch by name, not just by upstream shorthand, and inspect the branch graph.

git log --oneline --graph --decorate origin/main..HEAD

For a force push, it is also wise to inspect what would be removed from the remote side by reversing the comparison:

git log --oneline HEAD..origin/main

That shows commits on the remote branch that are not in your local branch. If this list is non-empty, a force push may overwrite work.

Common Pitfalls

A common mistake is relying on git status alone. git status tells you whether your branch is ahead of the remote, but it does not show the actual commits or patch content.

Another mistake is comparing against the wrong branch. If your branch tracks origin/develop but you diff against origin/main, your pre-push review is misleading.

Developers also forget to fetch before reviewing. If the remote moved and your local references are stale, your comparison may be outdated.

git fetch origin
git log --oneline @{upstream}..HEAD

Finally, uncommitted changes can create confusion. They are visible in your working tree but will not be pushed until committed.

Summary

• Use git log --oneline @{upstream}..HEAD to see commits you are about to push.
• Use git diff @{upstream}..HEAD or --stat to inspect the actual change set.
• Check tracking configuration with git branch -vv before trusting the comparison.
• Fetch first if you want an up-to-date view of the remote branch.
• Review more carefully before force pushing, especially what may be overwritten.