Branches — changing things without risking what works
You can commit. That means every saved moment is recoverable. Branches are the next thing: a way to try something large without the working version and the experiment ever being the same thing.
What a branch actually is
main is your line of commits. A branch is a second name pointing at the same moment, which then moves independently as you commit.
That is genuinely all it is. Not a copy of your files, not a separate folder. A name that moves.
git switch -c try-sorting # new name here, and go to it
# ...change things, commit, change more...
git switch main # back — your files are as they were
Switching back does not undo your work. The commits are still there under the other name, waiting.
Why this matters before course 1
In course 1 an assistant writes most of the code. You will ask for something substantial and get thirty lines back across four files. Two things can then be true at once: the change is interesting, and you are not sure about it.
On main, that is a decision under pressure — accept and hope, or refuse and lose the work. On a branch it is not a decision at all. Accept it, run it, read it, live with it for ten minutes. If it is good, merge it. If it is not, switch away and delete the branch, and nothing you cared about was ever at risk.
git switch main
git merge try-sorting # bring it in
git branch -d try-sorting # done with the name
Or, if it was not good:
git switch main
git branch -D try-sorting # capital D — throw it away unmerged
Branches are cheap, and that is the point
Making one costs nothing and takes a second. Delete them without ceremony. A branch is not a commitment to finish something; it is permission to try.
A useful habit: before you ask an assistant for anything bigger than a one-line change, make a branch. It costs a second and it changes the question from "is this safe?" to "is this good?" — and only the second question is worth your attention.
When two changes touch the same line
If main moved while you were on your branch and both changed the same line, merging stops and shows you both versions with markers. Git is not confused and nothing is lost. It is telling you that this one is a judgement call, because only you know which version is right.
You will meet this properly in course 5. For now, knowing it is a question rather than a disaster is enough.
Try it now
On the small program from unit 2, make a branch and change something you would not dare change on main — rename every variable, restructure a function. Commit it. Switch to main and confirm your files are back as they were. Then merge it in. Then do it once more, and throw the branch away instead.