Comprehensive Guide to Git Branching: Create, Switch, Delete

Git branching lets you work on a feature, fix, or experiment without disturbing the main line of development. A good branching habit keeps your changes organized and makes reviews, testing, and rollback much easier.

Branches are lightweight pointers to commits. That means creating, switching, and deleting them is fast, but the choices you make still affect how clearly your project history reads.

What a Git Branch Is

A Git branch is a movable name that points to a commit. When you commit new work on a branch, Git moves that branch name forward to the new commit.

Most projects have a primary branch such as main or master. Teams usually keep that branch stable, then create short-lived branches for specific work:

git switch -c fix-login-timeout

This creates a new branch and switches to it. Older Git examples may use:

git checkout -b fix-login-timeout

Both patterns are common, but git switch is easier to read because it focuses only on branch movement.

Branch names should be specific enough to explain the work. feature is too vague. feature/add-health-check-endpoint or fix/nginx-502-upstream-timeout is much better. A clear name helps you and your reviewers understand the branch before opening any files.

Creating and Switching Branches

Before creating a branch, start from the right base. For most teams, that means updating your primary branch first:

git switch main
git pull
git switch -c feature/add-metrics-endpoint

This reduces the chance that your new branch starts from stale code. It does not eliminate conflicts, but it gives you a cleaner starting point.

To list local branches, run:

git branch

The current branch has an asterisk next to it. To see remote branches too, use:

git branch -a

To switch to an existing branch:

git switch branch-name

If the branch exists only on the remote, you can usually create a local tracking branch with:

git switch --track origin/branch-name

Tracking matters because it connects your local branch to its remote counterpart. Once tracking is set, simple commands like git pull and git push know which remote branch to use.

For a concrete scenario, imagine you need to patch a Jenkins pipeline failure while also working on a larger Docker image cleanup. Put those changes on separate branches. The urgent patch can be reviewed and merged quickly, while the larger cleanup can continue without blocking it.

For related basics, see getting started with Git repositories.

Keeping Branches Organized

Branches become messy when they stay open too long or collect unrelated changes. The best branch is usually small, focused, and easy to review.

Use one branch for one purpose:

• A bug fix branch should include the fix and any related tests.
• A feature branch should include the feature, not drive-by refactors.
• A cleanup branch should avoid behavior changes unless they are clearly part of the cleanup.

Before pushing, check your work:

git status
git diff --staged

This catches accidental files and unrelated edits. It is especially useful in DevOps repositories where generated files, local config, and secret templates may sit near real source files.

When your branch needs the latest changes from main, you have two common options:

git merge main

or:

git rebase main

Merge preserves the exact branch history. Rebase rewrites your branch commits on top of the latest base. Both are useful, but teams should agree on which style they expect before merging shared work. If you are unsure, prefer the workflow documented by your project.

Deleting Branches Safely

Deleting old branches keeps your repository easier to navigate. After a branch has been merged, delete the local copy with:

git branch -d branch-name

The lowercase -d is the safer option. Git refuses to delete the branch if it believes the work has not been merged.

If you truly need to delete an unmerged local branch, use:

git branch -D branch-name

Use this carefully. It removes the branch name even if the commits are not merged. The commits may still be recoverable for a while through the reflog, but you should not treat that as a normal safety net.

To delete a remote branch:

git push origin --delete branch-name

Only delete remote branches when the work is merged, abandoned, or clearly owned by you. On shared teams, remote branches may be used by reviews, deployment previews, or other developers.

You can clean stale remote-tracking references with:

git fetch --prune

This removes local references to remote branches that no longer exist on the server. It does not delete real remote branches.

When to Ask a Teammate

Branch creation and switching are low-risk operations. The risky moments are deleting unmerged work, force-pushing, and rebasing branches that other people may already be using.

Ask before force-pushing to a shared branch. Also ask before deleting a remote branch that you did not create. In CI/CD-heavy repositories, a branch may trigger builds, previews, or deployment rules that are not obvious from Git alone.

Good branching is mostly about clarity. Create a branch from the right base, name it after the work, keep it focused, and delete it when it is no longer needed. Those habits make Git easier for you and safer for the whole team.