Alex: Welcome back. Challenge 4 is called Branch Out, and it is one of those small GitHub moves that makes everything after it safer. You're going to create a personal branch for Day 1 work, named `learn/YOUR-USERNAME`.

Jamie: This is the moment where I always want to ask the basic question. Why make a branch at all if I'm just practicing in my own private repository?

Alex: Because `main` is the stable copy of the project. A branch is a separate line of work, so you can try an edit, make a commit, and later open a pull request without changing `main` right away. If something goes sideways, your main branch is still clean.

Jamie: So the branch is not extra ceremony. It's a safety rail.

Alex: Exactly. And in the Learning Room, that safety rail is part of the real workflow: issue, branch, commit, pull request, review, merge. Challenge 4 is where that chain starts to feel practical.

Jamie: And just to ground where we are, this is happening in the Learning Room repository, not in the original template repository.

---

Alex: Your Learning Room is the private repository GitHub Classroom created for you from `Community-Access/learning-room-template`. Its name looks like `<workshop-org>/learning-room-<your-username>`, and it is where your Day 1 contributions happen.

Jamie: The setup path is: open the Classroom assignment link, identify yourself if GitHub Classroom asks, accept the assignment, and wait while GitHub copies the template into the workshop organization.

Alex: Right. When the repository link appears, open it and check a few landmarks: the repository name includes your username, you see files like `README.md`, and you see folders like `docs/` and `.github/`. Bookmark that page, because you'll come back to it all day.

Jamie: And the first challenge issue appears inside that repository, usually after the Student Progression Bot runs. If it doesn't show up after a couple minutes, refresh the Issues tab, then ask a facilitator if needed.

Alex: It's also worth checking the Actions tab once early on. You should see the pull request validation workflow, often called Gandalf, listed there. You don't need to run it yet; you just want to know that feedback will appear later when you open a pull request.

---

Jamie: There are two practice tracks in this workshop, right? I hear people mention GitHub Skills modules and the Learning Room, and they can sound similar.

Alex: They reinforce each other, but they are not the same. GitHub Skills modules are optional, self-paced practice in your own account, with GitHub's learning bot guiding isolated skills like opening a pull request or writing Markdown. The Learning Room is the required workshop track, where the Day 1 challenge issues, branches, commits, pull requests, checks, reviews, and merges happen.

Jamie: So the optional modules help build confidence, but the Learning Room is the shared workshop path.

Alex: Yes. In the Learning Room, the practice files are in `docs/`. You'll see `docs/welcome.md` with open source contribution sections to complete, `docs/keyboard-shortcuts.md` with screen reader shortcut references, `docs/setup-guide.md` with setup instructions, and `docs/CHALLENGES.md` as the challenge menu.

Jamie: And the repository is private, so I'm not seeing every other student's work in my copy.

Alex: Correct. Peer-simulation issues and pull requests inside your repository give you realistic collaboration practice. Facilitators may also pair students for real peer review when access is intentionally arranged, but your Learning Room starts as your own safe workspace.

---

Jamie: Let's create the Challenge 4 branch. Where should I be on GitHub?

Alex: Start on the Code tab of your Learning Room repository. Near the top of the file list, find the branch dropdown. Visually it usually shows `main`; with a screen reader, listen for a button labeled something like `Switch branches/tags`.

Jamie: Then I activate that button and type the branch name?

Alex: Yes. Type `learn/` followed by your actual GitHub username. So if your username is `octocat`, the branch name is `learn/octocat`. If your username is `student42`, the branch name is `learn/student42`.

Jamie: And then GitHub offers an option like `Create branch: learn/student42 from main`.

Alex: Activate that option. Now your branch exists on GitHub, created from the current state of `main`. For the evidence box in the challenge issue, write your branch name and a short sentence about how you created it.

Jamie: The issue also asks for a peer simulation check. Open the peer-simulation pull request, notice its branch name, and if you have a real buddy, ask whether they made their branch or help them find the dropdown.

---

Alex: The naming pattern for this challenge matters because facilitators and automation can recognize `learn/<username>` quickly. It keeps the room organized when many people are working at once.

Jamie: But I saw examples like `fix/welcome-todo`, `feature/add-schedule-link`, and `docs/update-readme` in the reference. Are those wrong?

Alex: No, those are common branch naming styles for regular project work. A pattern like `type/description` is short and descriptive, and you'll see it often. For Challenge 4, though, use the workshop pattern: `learn/` plus your username.

Jamie: What if GitHub says the branch already exists?

Alex: If you already created `learn/<your-username>`, you're done. Switch to it from the same branch dropdown and confirm the name. If you typed the name wrong, create a new branch with the correct name; the old one won't break anything.

Jamie: So the deeper skill is understanding that my work can live away from `main` until I'm ready to propose it.

---

Alex: You only need one tool for this challenge, but it's useful to know the same idea exists across tools. In VS Code with Git, you can create a branch from the Source Control area or by selecting the branch name in the bottom-left status bar and choosing to create a new branch.

Jamie: And in the terminal, the Git command would be `git checkout -b learn/your-username`, assuming I'm already in the repository and starting from `main`.

Alex: Exactly. In GitHub Desktop, use the Current Branch dropdown, choose New Branch, enter the name, and confirm it is based on `main`. With GitHub CLI, you might clone your Learning Room repository with `gh repo clone <workshop-org>/learning-room-<your-username>`, change into the folder, and then run the Git branch command.

Jamie: Before pushing later, I should check which branch I'm on, especially in a terminal.

Alex: Yes. `git branch --show-current` is a good habit. And later, when you create short pull request branches, keep them focused, link the related issue in plain text, and use documented command help like `gh pr --help` when you need the current options.

---

Jamie: How does this branch connect to pull requests? We haven't changed a file yet.

Alex: A pull request is a proposal to merge one branch into another, usually your working branch into `main`. The branch is where your change lives; the pull request is where people and bots review it, discuss it, and decide whether it is ready.

Jamie: So later, if I edit `docs/welcome.md` or fix something in `docs/setup-guide.md`, that edit happens on a branch first.

Alex: Right. In the web editor, GitHub can create a branch for you when you choose to propose changes. In Chapter 6 practice, beginners are usually encouraged to use a short-lived branch like `fix/yourname-issueXX` for a focused pull request, rather than mixing everything into the Day 1 practice branch unless a facilitator says otherwise.

Jamie: When opening the pull request, I need a title, a useful description, and a line like `Closes #42` to connect it to the issue.

Alex: Yes. Then the pull request page gives you several places to read. The Conversation tab has the description, comments, review discussion, and status checks. The Commits tab lists commits, the Checks tab shows automation details, and the Files changed tab shows the diff, which means the exact lines added, removed, or changed.

Jamie: For screen reader navigation, Browse Mode is usually the reading mode for headings, comments, and diffs, and Focus Mode is mainly for typing into fields.

Alex: Good distinction. GitHub's pull request interface also supports landmarks and tabs, and the Files changed experience includes better structure for the file tree and diff areas. If something about the interface seems different from a guide, use headings, buttons, landmarks, and the official GitHub accessibility references to re-orient.

Jamie: There are also draft pull requests for work that is not ready yet, reviewer requests when you want feedback, and review outcomes like comment, approve, or request changes.

---

Alex: Once you open a pull request in the Learning Room, Gandalf usually posts feedback in about 30 seconds. It may check whether you used a `Closes #XX` line, whether the description is detailed enough, whether the files are in the expected area, and whether there are basic accessibility issues like heading order, link text, or alt text.

Jamie: If the bot finds something, I don't have to panic. I read the comment, update the branch, and the checks can run again.

Alex: Exactly. Peer review works similarly, just with a person. A reviewer reads the description, checks the conversation, opens the diff, may leave inline comments, and may suggest changes. As the author, you respond, make updates if needed, and resolve conversations when the discussion is handled.

Jamie: And when review is approved, or when the workshop allows self-merge, the pull request can be merged into `main`.

Alex: After merging, GitHub may offer to delete the branch, and in real projects maintainers may choose merge commit, squash and merge, rebase and merge, or auto-merge when required checks pass. In the Learning Room, merging also lets the progression automation notice your completed work and open the next challenge.

Jamie: What about common problems? Like a reviewer doesn't respond, or I disagree with feedback, or the bot seems wrong?

Alex: Ask for help in the workshop channel, tag a facilitator when appropriate, and explain what you checked. Study groups are fine for talking through ideas, but your repository work should still show your own understanding. And if you are reading someone else's pull request by assignment, be specific, kind, and focused on the change.

---

Alex: If you're stuck on Challenge 4, start with the branch dropdown. It is near the top-left of the file list on the Code tab, and it may be announced as `Switch branches/tags`.

Jamie: If I finish and want to verify, I can use that same dropdown to switch to `learn/<my-username>` and confirm GitHub shows the branch name.

Alex: Yes. And for reliable facts beyond the workshop notes, use official GitHub documentation about Git, GitHub Flow, pull requests, the GitHub Accessibility Guide for pull requests, and the GitHub CLI help built into the tool.

Jamie: I like that this challenge is small. No file edit yet, no merge yet, just create the safe place where future work can happen.

Alex: That's the win. You made a branch from `main`, named it in the workshop pattern, recorded evidence in the issue, and practiced the first move of a real contribution workflow. From here, your changes have a place to land before they become a pull request.