Git terminology and default branches

↑

CLI examples labeled Bash work in Git Bash on Windows 10 and Windows 11, or Bash on Linux, with Git installed. Bash variable assignments such as DEFAULT_BRANCH=main are shell syntax; use Git Bash for these examples rather than pasting them into PowerShell or Command Prompt.

Git commands make more sense once you can distinguish a local branch, a remote repository, and a remote-tracking reference. Neither Git nor a hosting service requires every project’s default branch to be named main. Older repositories often use master; teams may also use another name.

Quick reference

Term	Meaning
`main` / `master`	Common, ordinary branch names. The repository chooses its own default branch.
`origin`	Conventional name of the remote that a clone sets up. It is a nickname, not a special Git keyword or URL prefix.
`origin/main`	Local remote-tracking reference for the last fetched `main` tip from remote `origin`. It does not automatically update when someone else pushes.
`HEAD`	Reference to the currently checked-out commit (usually through a local branch); detached HEAD points directly to a commit.
`upstream`	Can mean a branch’s configured tracking branch, or a second remote conventionally called `upstream` when working with a fork. They are different concepts.
`fetch`	Downloads objects and updates remote-tracking references without integrating into the working branch.
`pull`	Fetches and integrates into the current branch, using merge or rebase according to options/configuration.
`push`	Sends local commits and updates a server-side branch, subject to permissions.
`merge`	Combines histories; often creates a merge commit when branches diverge.
`rebase`	Replays commits onto another base, creating new commit IDs; coordinate before rebasing published shared history.

Open your repository and check Current Branch. To identify the hosting platform’s default branch, visit the repository settings on GitHub, where it is listed under Branches. On GitLab, check the repository’s Settings → Repository default-branch section if you have permissions. A branch listed in Desktop is not necessarily the default; verify before creating a feature branch.

git status --short --branch
git remote -v
git remote show origin
git branch -a

git remote show origin queries the remote and usually reports its HEAD branch if reachable. If set locally, git symbolic-ref refs/remotes/origin/HEAD shows the stored remote HEAD reference. A local remote HEAD may be unset or stale; check the server if unsure.

A real example with master

Suppose GitLab uses master as the default and the remote is named origin. First check the remote and save your uncommitted changes safely. Then:

DEFAULT_BRANCH=master  # Confirm this with the remote before using it.
git status --short --branch
git switch "$DEFAULT_BRANCH"
git fetch origin
git pull --ff-only origin "$DEFAULT_BRANCH"
git switch -c feature/42-tree-explorer

The same commands work for main simply by setting DEFAULT_BRANCH=main. Replace origin too if your remote has another name. Do not run git switch with uncommitted edits that you might lose or mix between branches; examine git status first.

Why origin/main differs from main

main is your local movable branch. origin/main records the most recently fetched tip of main on the named remote. When a colleague pushes new changes, your origin/main stays unchanged until fetch updates it. Even after fetch, main can remain behind until you integrate those commits with a fast-forward pull or another deliberate operation.

Upstream has two meanings

Running git push -u origin feature/example sets the feature branch’s tracking relationship, which lets a later git push know where to send commits. In a fork workflow, upstream may instead be a remote name pointing to the original project: origin could point to your fork and upstream to the original. The two uses are related to collaboration but not the same setting.

Check yourself: If origin/master moved after git fetch, did your local master automatically move? No. Does a feature branch named feature/x have to be on GitHub? No, it can exist only locally.

Continue with branches, daily workflow and Git reference.