Introduction

Creating a branch locally is only half of the workflow in Git. If you want that branch available on the remote and want future git push and git pull commands to work without extra arguments, you need to publish the branch and set its upstream tracking branch.

The Standard Command

The most common way to do both steps at once is:

git push -u origin my-feature

This command does two things:

1. pushes the local branch my-feature to the remote named origin
2. records origin/my-feature as the upstream branch for the current local branch

After that, you can usually run plain git push and git pull while on that branch.

If the branch does not exist locally yet, create and switch to it first:

git switch -c my-feature
git push -u origin my-feature

Older Git versions commonly use:

git checkout -b my-feature
git push -u origin my-feature

Both workflows are valid.

What "Tracking" Actually Means

A tracking branch is a local branch that remembers which remote branch it is associated with. That matters because Git uses that relationship for:

• default push destination
• default pull source
• ahead or behind status in git status
• shorthand references such as @{upstream}

You can inspect the relationship with:

git branch -vv

A line like the following shows that the branch is tracking the remote:

* my-feature 1234abc [origin/my-feature] Add login validation

Setting the Upstream Later

If you already pushed the branch without -u, you can still configure tracking afterward:

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

Or, while on the branch:

git push --set-upstream origin my-feature

That is useful if the first push happened through a GUI client or a custom command and the upstream was never recorded.

A Practical End-to-End Example

Here is a small workflow that you can run in a normal repository:

1git switch -c feature/report-export
2echo "export feature" >> notes.txt
3git add notes.txt
4git commit -m "Add report export notes"
5git push -u origin feature/report-export

From that point on:

git push
git pull

will use origin/feature/report-export by default, as long as you are still on feature/report-export.

Working with Different Remote Names

origin is only a convention. If your remote is named something else, use that name instead:

git remote -v
git push -u upstream my-feature

This shows up in fork-based workflows where:

• 'origin points to your fork'
• 'upstream points to the main project'

In that case, you usually push your feature branch to your fork, not directly to the main project.

Common Pitfalls

One common mistake is pushing the wrong local branch because the current branch was not checked first. Run git branch --show-current if there is any doubt.

Another problem is forgetting the remote name and assuming origin always exists. Some repositories use different names, especially in mirrored or enterprise setups.

People also confuse tracking with branch creation. git branch my-feature only creates a local branch reference. It does not publish the branch anywhere. The remote branch is created when you push.

A subtler issue happens when the local and remote branch names differ. That is supported, but it makes commands and status output harder to reason about. Unless there is a clear reason, keeping the same name on both sides is simpler.

Finally, if your push is rejected, the issue is often not the tracking setup. It may be authentication, permissions, branch protection, or a pre-receive hook on the server.

Summary

• Use git push -u origin branch-name to publish a branch and set upstream tracking in one step.
• After upstream is set, plain git push and git pull usually work from that branch.
• 'git branch -vv is a quick way to verify tracking status.'
• You can set the upstream later if the branch was already pushed.
• Tracking configuration does not bypass authentication or branch protection rules.