Branch

A branch is a named line of development in a repository. In practical terms, a branch is a label that points to a commit, and as you add new commits on that branch, the label moves forward with them.

Branches are one of Git's core ideas because they let you work on one change without disturbing another. Stable shared work usually lives on main, while new features might happen on feature/login and bug fixes on fix/startup-crash. Each branch gives that work its own place in the commit history.

Why branches exist

Branches make it easier to:

• work on features, fixes, or experiments independently
• keep incomplete work separate from stable code
• collaborate without everyone committing directly to the same line of history
• review changes before they are merged into a shared branch

Without branches, every change would have to happen in one continuous history. That quickly becomes hard to manage, especially when multiple people are working in the same repository.

How to think about a branch

It helps to think of a branch as a movable name attached to the latest commit in a line of work.

A --- B --- C  main
            ^
            HEAD

In this example, main names commit C, and HEAD shows that main is the branch currently checked out.

The same idea applies when you add a new commit on the currently checked out branch. For example, if main currently points to commit A and you create a new commit B on top of it, then:

• A is the parent commit of B
• B becomes the new commit that branch main points to
• HEAD moves with main and now points to B

Before:

A  main
^
HEAD

After committing B on main:

A --- B  main
      ^
      HEAD

For example:

1. You start on main.
2. You create a new branch called feature/login.
3. Both branch names initially point to the same commit.
4. You make two new commits on feature/login.
5. feature/login moves forward to those new commits, while main stays where it was.

Before new work:

A --- B  main, feature/login

After two commits on feature/login:

A --- B  main
       \
        C --- D  feature/login
                 ^
                 HEAD

This is why branches are lightweight in Git. Git is not copying the whole repository when you create one. It is mostly creating another pointer into the same commit graph.

The current branch

At any moment, you are usually working on one current branch. That is the branch new commits will be added to.

If you switch from one branch to another, Git updates your worktree to match the branch you checked out. This is why switching branches can change which files you see locally.

HEAD -> main

or after switching:

HEAD -> feature/login

The relationship between your current branch and HEAD is covered in History and HEAD, but the short version is that HEAD usually points to the branch you currently have checked out.

Creating and switching branches

A common workflow looks like this:

1. Start from a branch such as main.
2. Create a new branch for the work you are about to do.
3. Commit your changes on that branch.
4. Merge or rebase that work later, depending on the team's workflow.

When you create a branch, it starts from your current commit unless you explicitly base it somewhere else. That starting point matters, because it determines which history your branch begins from.

Switching branches does not delete your commits. It changes which line of development you are currently viewing and extending. If Git prevents a branch switch, it is usually because your uncommitted changes would be overwritten and need to be committed, stashed, or discarded first.

Branches after cloning

When you clone a repository, Git creates a local copy of the repository history on your machine and checks out one branch for you to work on.

In a typical clone:

• you get one current local branch, often main
• Git also records branch information from the remote repository
• that remote is commonly named origin

That means a clone does not leave you with only one possible branch forever. It gives you a starting local branch plus access to the wider branch structure of the repository.

Local branches

A local branch is a branch that exists in your copy of the repository.

This is the branch you:

• switch to when changing context
• commit to directly on your machine
• use for local feature work, fixes, or experiments

If you create feature/login locally, that branch exists only on your machine until you push it to a remote repository.

Remote branches and tracking

Repositories that are shared with a service like GitHub also have remote branches. In everyday Git usage, you will usually see them through names like origin/main or origin/feature/login.

Those names help you answer questions like:

• what branch exists on the remote
• whether your local branch is ahead or behind
• where your next push or pull will go

A tracking branch is a local branch configured to follow a branch on a remote. For example, your local main branch might track origin/main.

Local repository           Remote repository

main  ------------------>  origin/main
feature/login ---------->  origin/feature/login
experiment                 (no remote branch yet)

The arrows above represent tracking relationships, not copies of the whole repository.

When a local branch tracks a remote branch, Git can tell that:

• git pull should bring changes from that remote branch into your local branch
• git push should send your local commits to that remote branch
• ahead and behind counts should be compared against that remote branch

This tracking relationship is part of what makes normal day-to-day Git workflows feel automatic after the first setup.

Local branch vs tracking branch

These terms are related, but they are not the same:

• A local branch is any branch in your local repository.
• A tracking branch is a local branch with an upstream remote branch configured.

That means:

• every tracking branch is a local branch
• not every local branch is a tracking branch

For example, you can create a purely local experiment branch that tracks nothing, or you can create a branch that is specifically meant to follow origin/feature/login.

This page focuses on the branch model first. For more on the network side of the story, see Repository and Fetch, Pull, and Push.

Branches in GitComet

In GitComet, branch information helps you answer a few important questions quickly:

• which branch you are currently on
• whether you are looking at the main line of work or a side branch
• how your current work relates to other branches and shared history
• whether your local branch is connected to a remote branch

That distinction matters because many Git actions depend on the current branch. Commits, pulls, pushes, merges, and rebases all happen from a specific branch context.