Making and Switching Branches
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
git switch -c sightings-page git branch
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:
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.
Switching back
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:
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:
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.
- "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.
- "
switchandcheckoutare different features." For this purpose they do the same thing.switchis the newer, narrower spelling, introduced precisely becausecheckoutdid too much.
- 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
mainautomatically, 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
.gitdirectory 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