Chapter 4.1 — Branches Kya Hoti Hain☕ 10 min read

Branches Kya Hoti Hain

Branch = movable label. HEAD = tumhari current position. Detached HEAD = khatarnak zone, branch banao bhagne se pehle!

01Branch = Ek Pointer, Koi Folder Nahi

A branch is not a folder copy. A branch is not a separate copy of your project. A branch is simply a 40-character SHA-1 hash pointing to a commit. That is it. Just a pointer.

Creating a branch is O(1) — instant. Why? Because Git just writes 41 bytes (the hash + newline) to a file. No files are copied, no directories are created, no data is duplicated.

main is just another branch. Technically, there is nothing special about it. Culturally, it represents production — but Git treats it the same as any other branch.

Branch names are stored in .git/refs/heads/. Each file contains exactly one line: the SHA-1 hash of the commit it points to.

When you commit, the current branch pointer moves forward to the new commit. The old commit stays exactly where it was — the label just moves ahead.

Multiple branches can point to the same commit. Creating git branch feature when on main just adds a second label to the same commit.

# Create a branch (instant!)
git branch feature

# What did Git actually do?
cat .git/refs/heads/main
cat .git/refs/heads/feature
# SAME hash! Both point to the same commit right now.

# List branches
git branch        # * main, feature
git branch -v     # with last commit hash and message

Creating a branch is just writing 41 bytes to a file. This is why Git branches are fundamentally different from SVN branches, which actually copy the entire directory structure. Git branches are free — create as many as you need. In SVN, branching was expensive and avoided. In Git, branching is instant and encouraged.

02HEAD: Tum Ab Kahan Ho?

HEAD is a special pointer that tells Git where you are right now. It is how Git tracks your current position in the commit history.

Usually, HEAD points to a branch name (like ref: refs/heads/main). This is called an "attached HEAD" — it is attached to a branch.

When you commit, the branch that HEAD points to moves forward automatically. The branch pointer advances to the new commit, and HEAD follows because it is attached to the branch.

When you checkout a branch, HEAD moves to that branch. Simple as that.

Detached HEAD: This happens when HEAD points directly to a commit hash instead of a branch name. You got here by checking out a specific commit, a tag, or during a rebase. You can read code and run tests, but any new commits you make here are in danger of being lost.

cat .git/HEAD shows you exactly where HEAD points at any moment.

# Check where HEAD points
cat .git/HEAD
# ref: refs/heads/main  (HEAD is on main branch)

# Switch branches - HEAD moves
git switch feature
cat .git/HEAD
# ref: refs/heads/feature  (HEAD is now on feature)

# Detached HEAD - checkout a specific commit
git checkout abc1234
cat .git/HEAD
# abc1234... (HEAD points directly to a commit, NOT a branch!)
# Commits here can be lost if you switch away!

💡 Pro Tip: Always check cat .git/HEAD if you are unsure where you are. If it says ref: refs/heads/something, you are on a branch (safe). If it shows a raw hash, you are in detached HEAD (be careful!). The git status command also tells you if you are detached.

03Commits Form a Chain, Branches Are Labels

Each commit stores a pointer to its parent(s). This parent-child chain IS the history. Commit B points to Commit A. Commit C points to Commit B. The chain goes all the way back.

Branches are just movable labels stuck on a particular commit in that chain. Think of them like sticky notes. You can put a sticky note on any commit, move it to a newer commit, or remove it entirely.

When you commit on a branch, the label moves to the new commit. The commit chain grows, and the branch label follows along.

Deleting a branch only deletes the label, NOT the commits (immediately). The commits stay in the object store. They only become unreachable when no label points to them and the reflog expires (after ~90 days by default).

Understanding this mental model — commits = chain, branches = labels — is the key to mastering Git. Everything about branches makes sense once you see them as labels, not folders.

# Create commits and see the chain
echo "v1" > file.txt && git add . && git commit -m "v1"
echo "v2" > file.txt && git add . && git commit -m "v2"

# See the parent chain
git log --oneline --graph
# * def5678 (HEAD -> main) v2
# * abc1234 v1

# The branch "main" is just a label on def5678
# If we create a new branch, it just adds another label
git branch feature
# Now def5678 has TWO labels: main AND feature

A branch is a label, not a copy. When you delete a branch with git branch -d feature, Git only removes the label from .git/refs/heads/feature. The commits are still there in the object store. They become "unreachable" but are not immediately deleted. The Git garbage collector (git gc) eventually removes unreachable objects, but only after the reflog expires — typically 90 days. So if you accidentally delete a branch, you can almost always recover it.

04Detached HEAD: Khatarnak Zone

Detached HEAD happens when you checkout a commit hash, a tag, or during a rebase. HEAD points directly to a commit instead of a branch name.

You CAN read code, run tests, and inspect history in detached HEAD. It is not broken — it is just a state where new commits have no branch to belong to.

You SHOULD NOT make new commits in detached HEAD. They will be orphaned — when you switch to a branch, these commits have no label pointing to them, making them hard to find.

If you accidentally commit in detached HEAD, create a branch immediately: git branch save-my-work. This attaches a label to your commit, making it permanent.

To escape detached HEAD: git switch main or git switch - (go to previous branch).

Git explicitly warns you about detached HEAD for a reason — listen to the warning!

# Enter detached HEAD
git checkout HEAD~1
# Note: You are in "detached HEAD" state

# Accidentally made a commit here?
echo "orphan work" > file.txt
git add . && git commit -m "orphan commit"

# SAVE IT! Create a branch from here
git branch save-orphan

# Now escape
git switch main

# The orphan commit is safe on save-orphan branch
git log save-orphan --oneline

💡 Pro Tip: If you accidentally make commits in detached HEAD and switch away before creating a branch, all is not lost. Use git reflog to find the orphaned commit hash, then git branch recovered <hash> to save it. The reflog keeps track of every HEAD movement for about 90 days.

05Branching Strategies Overview

Branches are powerful, but you need a strategy for how to use them as a team. Without a strategy, you get chaos — long-lived feature branches, merge nightmares, and no one knows what is deployed.

Git Flow: Structured, multiple long-lived branches. main for production, develop for integration, feature/* for features, release/* for releases, hotfix/* for urgent fixes. Great for projects with scheduled releases.

Trunk-Based Development: Everyone commits to main (the trunk). Short-lived branches only (less than 1 day). Requires strong CI/CD and feature flags. Google and Facebook use this.

GitHub Flow: Simple — main + feature branches with Pull Requests. Deploy from main. Great for continuous deployment and small teams.

The right strategy depends on team size, release cadence, and CI/CD maturity. There is no one right answer.

We will deep dive into Git Flow (4.2) and Trunk-Based (4.3) in the next chapters.

# Git Flow branches
# main --- develop --- feature/login
#                  |-- feature/signup
#                  |-- release/1.0

# Trunk-Based branches
# main --- feat/short-lived-1
#       |-- feat/short-lived-2

# GitHub Flow branches
# main --- feature/add-payment
#       |-- feature/fix-header

# There is no one right way - choose based on your team!

The best branching strategy is the one your team actually follows. A simple strategy followed consistently beats a complex strategy followed poorly. Start simple (GitHub Flow), add structure (Git Flow) only when your team and release process demand it. Most teams over-engineer their branching strategy early on.

Lo kar liya — Key Points:

✅ A branch is just a pointer (SHA-1 hash) to a commit, not a folder copy — creating one is O(1)
✅ HEAD tells Git where you are right now — it usually points to a branch name
✅ When you commit, the current branch pointer moves forward to the new commit
✅ Detached HEAD occurs when HEAD points directly to a commit hash — commits here can be lost
✅ If you commit in detached HEAD, immediately create a branch to save your work
✅ Branching strategies (Git Flow, Trunk-Based, GitHub Flow) define how teams use branches

Previous3.8 — Rebase Conflict Resolution Flow 📋 All Chapters Next Chapter4.2 — Git Flow Strategy →