Making and Switching Branches
Topic 24

Making and Switching Branches

Branching

Two commands: one makes a branch and puts you on it, the other moves you between branches that already exist. The surprising part is watching your files change.

Create and switch in one step

Start work on the new sightings page
git switch -c sightings-page
git branch
Two labels now, and you are on the new one
  main
* sightings-page

The -c means "create". The new label was made at your current commit, which means both branches currently point at exactly the same place. Nothing has diverged yet.

Committing on a branch

Work as normal — edit, stage, commit. The only thing that changes is which label moves:

Two commits on the branch
git add sightings.js
git commit -m "Add the sightings list script"
git add index.html
git commit -m "Link the sightings list from the home page"

main has not moved. It still points at the commit it pointed at when you branched. The two versions of Sandpiper now genuinely differ, and both exist in the same folder.

Two labels, one chain, work only on one side
c8d1e07← main stayed here
1d4f8b2Add the sightings list
6e0a95c← sightings-page points here

Switching back

Go back to the version the club is using
git switch main

Open index.html now and the sightings link is gone. Look in the folder and sightings.js is not there at all. This is the moment the model becomes real: your folder shows one branch at a time.

Nothing was lost. Switch back and everything returns:

And back again
git switch sightings-page

Two commands, two versions of the project, one folder. Practise this a few times on Sandpiper until the disappearing file stops being alarming, because it is the single most common source of "Git deleted my work" panic and it is entirely harmless.

The older spelling

git checkout -b name creates and switches; git checkout name switches. They do the same jobs and appear in every tutorial written before 2019.

switch exists because checkout had accumulated too many unrelated responsibilities — switching branches, restoring files, visiting old commits — and one command doing three different things is how beginners get hurt. This book uses switch; recognize checkout when you meet it in the wild.

When Git refuses to switch

Sometimes the switch does not happen:

Git declining, for a good reason
error: Your local changes to the following files would be overwritten by checkout:
        index.html
Please commit your changes or stash them before you switch branches.
Aborting

Read it as a sentence. You have uncommitted changes to a file, and the branch you asked for has a different version of that same file. Switching would overwrite your work, so Git stopped.

Two ways forward, both one command. Commit the changes, if they are coherent. Or stash them — the drawer from the last chapter — if they are not. The message even tells you both. This is Git protecting you, and it is the most common branch-related message you will see.

Common Confusions
  • "Switching branches loses my commits." The commits stay attached to the branch you made them on. Switch back and they are all there, along with the files they contain.
  • "I need a separate folder for each branch." One folder, one repository, as many branches as you like. The folder's contents change to match wherever you are standing.
  • "My file was deleted when I switched." It exists on the other branch. Files created after a branch point only exist on that branch, which looks alarming exactly once.
  • "switch and checkout are different features." For this purpose they do the same thing. switch is the newer, narrower spelling, introduced precisely because checkout did too much.
Why It Matters
  • Watching the files change is the moment the label-that-moves model becomes concrete rather than theoretical, and it is worth doing deliberately rather than discovering by accident.
  • The refusal message is the most common branch-related obstacle a beginner meets, and knowing its two one-command fixes turns it into a non-event.
  • Creating a branch for a small change is a habit worth building now, because Chapter 8's entire workflow assumes it.

Knowledge Check

You create a branch, make two commits on it, then switch back to main. Where are those commits?

  • Still on the branch you made them on, and they return when you switch back
  • Merged into main automatically, since it is the project's primary branch
  • Deleted, because a branch only keeps commits while you are standing on it
  • Copied to both branches, so the same work now exists twice in the history

A file you created on a branch disappears when you switch to main. What happened?

  • It exists only on the other branch, so your folder no longer shows it
  • Git deleted it because it was never committed on the branch you switched to
  • The switch failed part way through and left the folder in a broken state
  • It was moved into the .git directory and needs restoring by hand

Git refuses to switch, saying your local changes would be overwritten. What are the two fixes?

  • Commit the changes if they are coherent, or stash them if they are not
  • Delete the changes with git restore, or delete the branch you are on
  • Force the switch with an option, or clone the repository again from scratch
  • Wait for Git to finish an operation, or run the command from a different folder

What does -c do in git switch -c sightings-page?

  • It creates the branch at your current commit and then moves you onto it
  • It copies the current branch's files into a new folder for the new branch
  • It clears the working directory so the new branch starts from an empty state
  • It connects the new branch to the previous one so changes flow between them

You got correct