Git Branching

What a Branch Really Is

A branch in Git is a movable pointer to a commit. Instead of copying your whole project into a new folder, Git lets you create a lightweight branch and continue work there.

This is one of Git’s biggest strengths. You can build a feature, fix a bug, or test an idea without disturbing the main line of development.

Tip: A branch is not a second copy of the project. It is a label that points to a specific place in commit history.

Why Branching Matters

Imagine the main branch contains stable application code. You want to add a login page, but the work may take several commits. Instead of changing main directly, you create a feature branch.

Benefits of branching:

• isolate work in progress
• reduce risk to stable code
• make code reviews easier
• support multiple parallel changes

In real teams, short-lived feature branches are common because they keep the shared branch clean.

Viewing Branches

To list local branches:

git branch

The current branch is marked with *.

To see both local and remote branches:

git branch -a

A typical result might be:

* main
  feature/login
  remotes/origin/main

Creating a Branch

Create a new branch called feature/login:

git branch feature/login

This creates the branch, but you stay on your current branch until you switch.

To create and switch in one step, use:

git switch -c feature/login

Older tutorials may use git checkout -b feature/login, which still works, but git switch is clearer for branch changes.

Switching Between Branches

Move to an existing branch:

git switch main

Switch back:

git switch feature/login

When you switch branches, Git updates your working directory to match the selected branch’s latest commit.

Real Example

git switch -c feature/navbar
echo "Add navigation" >> README.md
git add README.md
git commit -m "Document navbar plan"
git switch main

After switching back to main, that change is no longer visible there because it belongs to the feature branch.

Understanding HEAD

HEAD is Git’s way of saying “your current position.” Most of the time, HEAD points to the branch you are currently on.

If you are on main, HEAD points to main, and main points to the latest commit on that branch.

You can inspect recent history with:

git log --oneline --decorate -5

You may see output like:

7fa12cd (HEAD -> feature/login) Add login form markup
1ab93e0 (main) Create app skeleton

That means HEAD currently points to feature/login.

Deleting a Branch

After a branch has been merged and is no longer needed, delete it to keep the repository tidy.

Delete a fully merged branch safely:

git branch -d feature/login

Force delete a branch that has unmerged commits:

git branch -D feature/login

Note: Use -D carefully. It can remove a branch pointer before its work is merged elsewhere.

Detached HEAD Explained

A detached HEAD happens when HEAD points directly to a commit instead of a branch.

For example:

git checkout 1ab93e0

Now you are no longer “on” main or feature/login. You are looking at a specific past commit.

This can be useful for inspection, testing, or reproducing an old state. But if you make commits here, they are not attached to a branch unless you create one.

Safe Way to Continue from Detached HEAD

If you decide to keep that work, create a branch immediately:

git switch -c investigate-old-release

That gives the new commits a proper branch name and keeps them easy to find.

Good Branch Naming Habits

Teams usually prefer simple, descriptive names such as:

• feature/login-page
• fix/pipeline-timeout
• docs/git-tutorial
• hotfix/rollback-script

A good branch name helps everyone understand the purpose of the work.

A Practical Branch Workflow

Here is a realistic beginner workflow:

git switch main
git pull
git switch -c feature/add-footer
echo "Footer content" >> index.html
git add index.html
git commit -m "Add footer to homepage"
git switch main

At this point, main stays stable while the new work lives on feature/add-footer until it is reviewed and merged.

What You Should Remember

Branches are lightweight and powerful. Use them to isolate work, protect stable code, and make collaboration easier. HEAD represents your current location in history. Most of the time it points to a branch, but during detached HEAD it points directly to a commit.

If you remember one best practice, remember this: create a branch before doing meaningful new work.

Test Your Understanding

Exercise 1: Creating isolated work

Scenario: main is stable and you want to build a new navbar without disturbing it.

Question: Which command both creates and switches to the feature branch in one step?

Exercise 2: Reading HEAD correctly

Question: In git log --oneline --decorate, you see (HEAD -> feature/login) next to the latest commit. What does that mean?

Exercise 3: Escaping detached HEAD safely

Scenario: You checked out an old commit to investigate a bug and now want to keep new work you started there.

Question: What is the safe next step from the lesson?

---

Frequently Asked Questions

What is the difference between git switch and git checkout?

git checkout does several unrelated jobs, moving between branches, creating them, and restoring files, which made it a common source of accidents, since git checkout <file> silently discarded changes. Git split those responsibilities: git switch changes branches and git restore restores files. git switch -c <name> replaces git checkout -b <name>. Both new commands are stable and preferred in new work; checkout still functions and is not going away, so older documentation remains valid.

What does "detached HEAD" mean and how do I fix it?

HEAD normally points at a branch name, which in turn points at a commit. When you check out a commit, tag, or remote-tracking branch directly, HEAD points straight at that commit with no branch attached, that is detached. You can look around and even commit, but those commits belong to no branch and become unreachable once you leave. If you have made commits you want to keep, git switch -c <new-branch> right where you are captures them. If you have not, git switch main returns you to normal.

How do I delete a local and a remote branch?

git branch -d <name> deletes a local branch and refuses if it holds commits not merged anywhere, which is a safety net worth keeping; -D forces it. For the remote, git push origin --delete <name>. Deleting a remote branch does not remove other people's stale local copies of it. They need git fetch --prune, or git config --global fetch.prune true to have it happen automatically on every fetch.

How do I rename a Git branch?

git branch -m <new-name> renames the branch you are on, or git branch -m <old> <new> for another one. Renaming a branch that exists on the remote takes three steps, because the remote branch is a separate reference: rename locally, push the new name with git push origin -u <new-name>, then delete the old one with git push origin --delete <old-name>. Anyone else working on it needs to re-point their local branch, so agree the change first.

What is a good branch naming convention?

Use a short prefix that says what kind of change it is, then a brief description in kebab-case: feature/user-search, fix/login-redirect, chore/bump-deps. Many teams add the ticket number, feature/PROJ-412-user-search, which lets tooling link branches to issues automatically. Keep them lowercase and avoid spaces and unusual characters, since branch names become part of URLs and filesystem paths. The value is not aesthetic: a consistent scheme makes git branch --list 'fix/*' and automated cleanup possible.

Does creating a branch in Git copy all my files?

No, and this is why Git branching is fast where older systems were slow. A branch is a 41-byte file containing a commit hash. A pointer, nothing more. Creating one writes that file and does not touch your working directory at all, which is why git switch -c is instant even in a huge repository. Switching branches then updates only the files that actually differ between the two commits.