Push, Tracking Branches, and the Push/Pull Loop

In one line

git push sends your local commits to a remote, tracking branches remember which remote branch your local one corresponds to, and the push/pull loop is the entire daily rhythm of working with a shared repository.

0/4 · 0%

Key ideas

01
git push <remote> <branch> uploads your local branch's commits to the named remote, updating that remote's copy of the branch to match yours — this is the ONLY way your local commits ever become visible to anyone else, since everything before this point exists purely on your own machine.
02
A TRACKING BRANCH (or 'upstream branch') is a local branch's remembered association with a specific remote branch — once set, a bare git push or git pull with no arguments knows exactly which remote and branch to use, without you specifying them every time. git push -u origin <branch> ('set upstream') establishes this tracking relationship the FIRST time you push a new local branch.
03
git branch -vv shows every local branch alongside its tracking branch (if any) and whether it's ahead, behind, or diverged from it — genuinely useful for a quick 'what's my actual sync status' check across every branch in a repository at once.
04
A push is REJECTED if the remote branch has commits your local branch doesn't have (someone else pushed first) — Git refuses to overwrite history it doesn't know about, forcing you to pull (or fetch + merge/rebase) those new commits first, incorporating them locally, before your push can succeed.
05
The everyday loop, repeated constantly on any real shared project: git pull (get the latest), make your changes, git add/git commit, git pull again (catch anything new since you started), resolve any conflicts, git push — this exact cycle, done frequently in small increments, is what makes collaborative Git work smoothly rather than in occasional, painful, giant merges.
06
git push origin --delete <branch> deletes a branch on the REMOTE (distinct from git branch -d, which only deletes your LOCAL copy) — the standard way to clean up a feature branch on GitHub/GitLab after its pull request has been merged, whether done manually or via the platform's own 'delete branch' button.

Code & diagrams

push-tracking.shmarkdown

The complete push/pull loop, including establishing tracking on a new branch.

cd ~/scratch/my-first-repo

# First push of a brand-new branch — establishes tracking
git switch -c feature/new-thing
echo "new work" >> feature.txt
git add feature.txt && git commit -m "Start new feature"
git push -u origin feature/new-thing
# from now on, plain "git push" / "git pull" work on this branch

# Check tracking status for every local branch at once
git branch -vv

# The everyday loop
git pull                          # get anything new first
echo "more work" >> feature.txt
git add feature.txt && git commit -m "Continue feature"
git pull                          # catch anything new since you started
git push                          # send your commits

# After the feature is merged and no longer needed
git branch -d feature/new-thing              # delete local copy
git push origin --delete feature/new-thing   # delete remote copy

Explain it without notes

Why does git push sometimes get rejected with a message about the remote containing work you don't have locally?

What's the difference between git branch -d and git push origin --delete for the same branch name?

Practice

Create a new local branch, push it for the first time with -u to establish tracking, then confirm with git branch -vv that the tracking relationship is set up correctly.

Simulate a rejected push: have one commit exist only on a remote's copy of a branch (or ask a teammate to push one) while you also have a local, unpulled commit, then experience the rejection and resolve it with a pull.

Trade-offs

↔
Pushing and pulling frequently, in small increments, keeps conflicts small and manageable when they do happen — going a long time between pushes (a common temptation when heads-down on a big feature) trades short-term focus for a genuinely higher risk of a large, painful conflict resolution later, once your branch and the remote have drifted far apart.

Done when you can

I can push a new branch and establish tracking with git push -u.
I understand why a push can be rejected and how to resolve it.
I know the difference between deleting a branch locally versus deleting it on the remote.