Introduction

Creating a branch in Git and publishing a branch to a remote are two separate actions. That separation is deliberate. A local branch is private workspace inside your repository, while a pushed branch is a shared reference that other repositories, teammates, and CI systems can see.

Local Branches and Remote Branches Are Different Refs

When you run this:

git switch -c feature/login-flow

Git creates a local branch reference only. Nothing has been written to origin or any other remote repository yet. At that point:

• your local repository knows about feature/login-flow
• the remote repository does not
• teammates cannot fetch it
• remote CI cannot build it

This surprises people at first, but it follows Git's core model: every repository is independent until you explicitly exchange refs and objects.

Why Git Does Not Auto-Publish New Branches

If Git pushed every new local branch automatically, it would create several problems:

• temporary experiments would clutter the remote
• unfinished work would trigger CI unexpectedly
• private or sensitive branches could be published by accident
• branch creation would become a network operation instead of a local one

Git chooses the safer default. Creating a branch is cheap and private. Publishing it requires an explicit decision.

What the First Push Actually Does

The first push does two things:

1. sends the commits the remote does not have
2. creates the branch ref on the remote

For a new branch, the usual command is:

git push -u origin feature/login-flow

The -u flag sets upstream tracking, which tells your local branch which remote branch it should use for future git push and git pull commands.

Why Existing Branches Feel Automatic

Once the remote branch exists and upstream is configured, later pushes feel effortless:

git push
git pull

That can make the first push seem inconsistent, but it is really a one-time setup step. The first push creates the remote branch relationship. Later pushes only update an already established relationship.

Upstream Tracking Is the Missing Link

Without upstream tracking, Git has no default answer to questions such as:

• which remote should this branch push to
• which remote branch should it update
• which remote branch should git pull merge from

That is why the first push often needs more information. Once Git knows the mapping, the short forms become convenient and predictable.

Example Workflow

A typical branch publication flow looks like this:

1git switch -c feature/payment-retry
2git add .
3git commit -m "Add retry backoff"
4git push -u origin feature/payment-retry

Only after the final command does the branch become visible on the remote and ready for review, collaboration, or pull request creation.

Common Pitfalls

The biggest mistake is assuming a local branch is automatically backed up remotely. It is not. Until you push it, the branch exists only in your local repository.

Another issue is forgetting -u on the first push, then wondering why a later plain git push or git pull asks for more information. The branch was published, but the tracking relationship was never recorded.

People also sometimes treat every local branch as something that should exist on the remote. In practice, many branches are disposable experiments, and Git's explicit push model helps keep them private.

Finally, some tooling softens the first-push experience with configuration such as push.autoSetupRemote, but that does not change the underlying model. Branch creation and remote publication are still separate concepts.

Summary

• A new local branch is private until you push it to a remote.
• Git separates branch creation from publication on purpose.
• The first push both transfers commits and creates the remote branch ref.
• Using git push -u origin <branch> also records upstream tracking for later commands.
• Explicit publication prevents accidental sharing, remote clutter, and surprise CI runs.