Remotes: fetch, pull, push and tracking

Remote-tracking branches

origin/main is a local ref recording where main was on the remote the last time you fetched. It is not live. If a colleague pushes right now, your origin/main is stale until you fetch again.

That is why 'your branch is up to date with origin/main' can be wrong — it is a statement about your last fetch, not about the server.

git fetch origin              # update remote-tracking refs only
git log --oneline HEAD..origin/main   # what they have that I do not
git log --oneline origin/main..HEAD   # what I have that they do not

git merge origin/main         # merge commit if both diverged
# or
git rebase origin/main        # replay my commits on top — linear

Note: git pull does fetch plus one of these. Doing them separately means you see what is arriving before it touches your branch.

Pull with rebase

Default pull merges, which on a busy shared branch produces a stream of 'Merge branch main of...' commits that carry no information. Setting pull.rebase to true replays your local commits on top of the fetched ones instead, keeping history linear.

The caveat is that rebasing rewrites your local commits. That is fine while they are only yours, and it is why the setting is safe for feature work and dangerous for a branch others have pulled.

Rejected pushes

A non-fast-forward rejection means the remote has commits you do not. That is Git protecting someone else's work, not an error to be forced past. Fetch, integrate by merge or rebase, then push normally.

A rejection after you deliberately rewrote history — an amend or a rebase of your own feature branch — is the one case where a force push is correct, and it should still be --force-with-lease.