Branches: Working Without Breaking Things

1This morning's near-miss

Earlier today, two people were working in this exact repository at the same time, both with reason to touch the homepage's index.html and _assets/hermetic.css. Neither wanted to overwrite the other's work, so before touching either file, each one sent a message like this:

That exchange repeated several times over the course of the morning, and it worked, because both sides were careful. But notice what it actually required: two people pausing their own work, every single time, to ask permission and wait for an answer, for the entire day, on every file either of them might touch. That is exactly the coordination cost a tool can remove, and a branch is that tool.

2What a branch actually is

A branch is a name that points at one commit. When you make a new commit while on a branch, the name moves forward to point at the new commit instead. That is the entire mechanism. Nothing about a branch copies the project to a new folder or duplicates any files on disk; switching branches simply changes which commit's snapshot is sitting in your working tree right now.

main is not special to git in any technical sense. It is a branch with a conventional name, the one most teams treat as the published, trustworthy line of work. Every other branch starts as a copy of wherever it was created from, usually main, and from that point on, commits made on one branch do not appear on the other until something explicitly brings them together. Session 05 covers that step, called a merge.

3Why main has to stay safe to publish

Session 02 covered the pipeline: a push to main on GitHub is the one event that makes Cloudflare Pages rebuild this training site, and Entra ID is the only thing standing between that rebuild and every signed-in member of staff. A half-finished change pushed straight to main does not stay private while you finish it. It goes live, behind Entra, to everyone with access, the moment the build completes.

A branch gives you a safe place to be unfinished. You can commit a broken page, an unfinished paragraph, or an experiment that goes nowhere, as many times as you like, and none of it reaches main, GitHub's default view of the repository, or the published site, until you decide to bring it across.

4Creating and switching branches

Older material, and some tools, use git checkout -b new-branch-name for the same job as git switch -c. Both exist in current git; this course uses switch because its name says what it does.

Name a branch for what it contains, briefly: git-course, homepage-cards, fix-footer-link. The name exists for people, including you in a month, to recognize at a glance; git itself does not care what it is called.

5When a branch is worth creating

Not every change needs one. Fixing an obvious typo you will commit in the next thirty seconds is fine directly on main, on a quiet repository with one person working on it. A branch earns its keep once any of these is true:

• The change will take more than a few minutes, so main would sit in a half-finished state in the meantime if you committed directly to it.
• You are not certain the change is right and want the freedom to abandon it without any trace on main.
• Someone else might be touching the same file today, which this morning's example showed is a real, not hypothetical, situation on this repository.
• The change is anything a reasonable person would want reviewed before it reaches a published, Entra-gated site.

6Try it: branch, commit, switch back

In your practice folder from session 01, which already has two commits from session 03.

1. Run git branch. You should see one branch, likely named main or master depending on how it was created, with an asterisk marking it current.
2. Run git switch -c try-a-branch. Run git branch again and confirm the asterisk moved to the new name.
3. Edit notes.txt again, adding a third sentence. Stage and commit it on this branch.
4. Run git switch main. Open notes.txt. The third sentence is gone, because that commit exists only on try-a-branch and main never received it.
5. Run git switch try-a-branch again. The third sentence is back. Nothing was lost; it was never on main to begin with.

7Check for understanding

1. What does switching from main to another branch actually change?

   A.It copies the entire project into a new folder named after the branch. B.It updates the files in your working tree to match that branch's most recent commit. C.It pushes your current commits to GitHub under the new branch name. D.It creates a brand new, empty repository.
   Answer

   A branch is a name pointing at a commit. Switching to it changes your working tree to match that commit's snapshot. No files are copied to a new location, and nothing is sent to GitHub just by switching.

   Show the answer
2. A commit is made on a branch called homepage-cards. Does it appear on main?

   A.Yes, immediately, since all branches share the same history. B.No. It exists only on homepage-cards until it is explicitly merged into main. C.Only after the next git push, which applies every branch's commits to main automatically. D.Only if the branch name contains the word main.
   Answer

   No. A commit lives only on the branch it was made on until a merge, covered in session 05, deliberately brings those commits onto another branch. This is exactly what let this morning's two streams of work coexist safely once separated onto their own branches.

   Show the answer
3. Why does a half-finished change pushed directly to main carry real risk on this repository specifically?

   A.Because GitHub automatically rejects any commit that looks unfinished. B.Because a push to main triggers Cloudflare Pages to rebuild and publish the site, and Entra ID only controls who can view it, not whether it is finished. C.Because any branch name other than main is ignored entirely by Cloudflare Pages. D.Because git marks commits on main as drafts automatically until reviewed.
   Answer

   Session 02's pipeline runs on exactly one trigger: a push landing on main. Entra ID decides who can view the result, not whether the content behind it is finished. So a half-finished push to main is visible to every signed-in staff member as soon as the rebuild completes, which is why unfinished work belongs on its own branch instead.

   Show the answer
4. Two technicians are both planning to touch _assets/hermetic.css today, each for an unrelated reason. What does session 04 suggest instead of the message-first-and-wait approach from section 1?

   A.Agree that only one of them is allowed to use git that day. B.Each creates their own branch for their change, works independently, and merges into main when ready. C.One of them locks the file on GitHub so the other cannot open it. D.They keep messaging each other before every edit, since that worked earlier today.
   Answer

   Giving each person their own branch removes the need to ask permission before every edit. Each works freely, and the two streams of change only need to interact once, at merge time, which session 05 covers, rather than before every single edit all day.

   Show the answer
5. What is main, technically, to git?

   A.A branch git protects automatically from ever being deleted or rewritten. B.A branch with a conventional name, treated by this team as the one connected to publishing, but not technically different from any other branch. C.A separate repository that other branches are copied into. D.The only branch name git allows by default, fixed and unchangeable.
   Answer

   To git, main is a branch like any other: a name pointing at a commit, nothing more. Its significance, as the branch connected to publishing and treated as the trustworthy default, is a convention this team follows, not a rule git enforces on its own.

   Show the answer

8Before session 05

• Keep try-a-branch in your practice folder. Session 05 merges it into main.
• Notice any place at work where two people might reasonably want to edit the same file on the same day. That is the scenario session 05's conflict example reuses.

9Glossary

Branch

A name pointing at a commit, moving forward as new commits are made while that branch is checked out.

Main

The branch, by convention, treated as the trustworthy default and connected to publishing. Not technically different from any other branch.

Switch (checkout)

Changing the working tree to match a different branch's commit. git switch and the older git checkout -b do this job.

Feature branch

A branch created to hold one piece of work until it is ready to merge.

10Sources

• Scott Chacon and Ben Straub, Pro Git, 2nd edition, chapter 3, "Git Branching."
• GitHub, GitHub flow, for the standard branch-then-merge pattern most teams follow.
• The coordination messages quoted in section 1 are this repository's own session record, 2026-10-03.