Branches: Parallel Universes for Your Code

Previously in Part 3, you learned to read history with log and diff, and rescued yourself from small mistakes with restore and --amend.

Today: the feature that made Git famous. And first, a fear I'd like to personally defuse. In the old tools I grew up on — SourceSafe, SVN — branching meant heavyweight ceremony: slow copies, dread, and a merge day people scheduled like dental surgery. Some teams simply banned it. If you've absorbed second-hand fear that "branching is advanced," please set it down here at the door. In Git, branching is not the scary advanced topic. It is the whole point.

A branch is a sticky label

Here's the secret that makes the figure above unscary: a branch is not a copy of your project. It's a movable sticky label pointing at one commit on the line. master is just a label stuck on a commit. Creating a branch means writing a second label and sticking it on the same commit — which is why it's instant and free. As you commit on a branch, its label slides forward along your new photos, while master's label stays where you left it. Two labels, two parallel universes, one album.

The workshop levels up: a real project

Our little clinic-notes folder was perfect for learning the moves, but branches deserve realistic material. So today you get the companion repository I promised in Part 1. Go to a folder outside clinic-notes and run:

git clone https://github.com/rahulvyas777/coder000-git-workshop.git
cd coder000-git-workshop

clone means: copy the entire album — every commit, all history — onto your machine. Inside you'll find ClinicApp, a small patient-management app. It's the same app this site's Blazor series builds, but let me stress: you need zero C# knowledge today. We won't run it or understand it — it's simply a real project with a real history, which is exactly what branching practice needs. Look at the history you just received:

git log --oneline

d4f8a2c (HEAD -> master, tag: v1.0, origin/master) Polish the home page welcome text
b7e91c3 Show a patient count above the list
a3c52f1 Tidy up the search filter
9f1d8e4 Add the new-patient form with validation
8c4b7a2 Add the patient details page with a route parameter
7e2f9d5 Move patients into a PatientService with dependency injection
6a8c3b1 (tag: v0.1) Add live search to the patients list
5d9e4f2 Add the Patients page with a seeded list
4b7a1c8 Show three patients on the home page
3f2d8e9 Add the PatientCard component
2c5b9a4 Add the Patient model
1a4f7d3 Initial commit: Blazor Web App template plus workshop README

That's not a mock-up — that's the actual history sitting on your disk right now (the serial numbers in your terminal will differ from my snippet, but the captions will match exactly). Read it bottom to top and you can watch the app grow, commit by commit, like a photo album of a child growing up. This is what good history looks like.

Create a universe

Let's say we want to add a notes field to patients, and we want to experiment without disturbing master. Write a new sticky label and jump to it, in one command:

git switch -c add-notes-field

Switched to a new branch 'add-notes-field'. The -c means create. Nothing was copied; Git wrote one label. Now make a change: open ClinicApp/Patient.cs in any editor and add one line inside the class, so it looks like this:

public class Patient
{
    public int Id { get; set; }
    public string Name { get; set; } = "";
    public int Age { get; set; }
    public string Notes { get; set; } = "";   // your new line
}

(If your copy of the class has a few more properties than shown, no problem — just add the Notes line alongside them.) Save, then commit on your branch:

git add ClinicApp/Patient.cs
git commit -m "Add a Notes property to Patient"

The magic moment

Now do this. Keep Patient.cs open in your editor if you can, and run:

git switch master

Look at the file. Your Notes line is gone. Not deleted — you're simply standing in the universe where it never happened. master's label points at a commit that doesn't include your change, so Git rebuilt the folder to match. Now:

git switch add-notes-field

And it's back. Switch a few more times and watch the file flicker between realities. The first time I saw this, it honestly felt like a magic trick — the same folder, physically rewritten in a blink, with both versions perfectly safe. This is what SourceSafe-era developers were never allowed to have: experiments that cost nothing and risk nothing. Master hasn't been touched. You can try any idea, however wild, on a branch.

Merging the easy way

Our experiment worked, so let's bring it home. Merging happens from the branch you want to receive the changes, so stand on master and pull the work in:

git switch master
git merge add-notes-field

Updating d4f8a2c..e5b3c9a
Fast-forward
 ClinicApp/Patient.cs | 1 +
 1 file changed, 1 insertion(+)

See the word Fast-forward? It means Git noticed something pleasant: while you worked on your branch, master didn't move at all. Your branch's history is just master's history plus one commit at the tip — so there was nothing to actually combine. Git simply slid the master sticky label forward onto your commit. No new commit, no drama; the two labels now sit on the same photo.

Throw away the label, keep the photos

The branch has done its job, so clean up:

git branch -d add-notes-field

Deleting a merged branch deletes only the sticky label — the commit it pointed to is safely in master's history now; run git log --oneline and see your commit sitting proudly on top. This is the healthy rhythm of Git: labels are cheap and disposable, commits are forever. Branch, commit, merge, delete, repeat — many professionals do this several times a day.

But notice how gently the universe treated us: master politely stood still while we worked. What if it hadn't? What if two branches each changed the same line of Patient.cs — and then tried to merge? Git will need your help, and that conversation has a scary name and a friendly reality. In Part 5: merge conflicts, explained without fear.