Alex: Welcome back. Day 2 begins with Challenge 10: Go Local, and the shift is pretty big. Yesterday, GitHub.com handled a lot for you in the browser. Today, you bring the repository down to your computer, make a change locally, and send it back up.

Jamie: So this is the moment where Git stops feeling like a website button and starts feeling like an actual development workflow.

Alex: Exactly. The goal is simple: clone a repository, create a branch, edit a file, commit your change, and push that branch to GitHub. The change itself can be tiny. The workflow is the thing you're practicing.

Jamie: And the challenge title is doing a lot of work there: Go Local. We're proving that work done on your computer can still become part of a GitHub project.

---

Alex: Before the steps, let's steady the mental model. A remote repository is the copy on GitHub. A local repository is the copy on your computer, including a hidden .git folder where Git stores history.

Jamie: That two-copy idea helps. If I edit locally, GitHub doesn't magically know yet.

Alex: Right. Your local work moves through three areas. First, the working directory, which is the folder and files you can open and edit. Then the staging area, which is a holding place for the changes you want in the next commit. Then the repository history, where the commit is saved as a snapshot.

Jamie: So editing is not the same as committing. And staging is that middle step where I choose what belongs in the save point.

Alex: Yes. A commit records the staged snapshot, a message, the author, and a pointer to the previous commit. Git also gives it a unique hash, though most of the time you'll only hear or see the short version, around seven characters.

Jamie: And branches are how we keep work separate from main, right?

Alex: That's it. The default branch is usually main. When you create a branch, you're making a parallel line of work so your edit can be reviewed or tested without disturbing main. Git uses HEAD to track which branch you're currently on.

Jamie: Then push is the moment I share my local commits with GitHub. Pull brings GitHub's changes down and merges them, and fetch checks what's new without changing my files yet.

Alex: Perfect. And if two people change the same part of the same file, Git may need help deciding what to keep. That's a merge conflict. It is normal, and VS Code gives tools for reviewing those changes when it happens.

---

Jamie: What should learners have ready before starting this one?

Alex: You should have VS Code available for Day 2, though GitHub Desktop and the command line are also supported paths. If you're joining Day 2 without Day 1, that's okay if you already know the basics: repositories, issues, pull requests, and reviewing changes. The Day 2 Quick Start is there to check accounts, tools, and comfort level in about 30 minutes.

Jamie: And the repository choice matters here, because there are practice repos and learner repos floating around.

Alex: Use the repository URL given in your Challenge 10 issue or by your facilitator. In many cohorts, that is your private Learning Room repository, the one GitHub Classroom provisioned for you. Some practice material uses the sci-fi themes repository, with the URL https://github.com/Community-Access/vscode-sci-fi-themes.git. What you should not do is clone the facilitator template unless you were specifically told to maintain it.

Jamie: So if the instructions say Learning Room, I clone my own private Learning Room copy. If the issue gives the sci-fi themes URL, I use that. Either way, the pattern is the same.

---

Alex: Let's walk the VS Code path first, because it's the recommended Day 2 route. Open VS Code, then open the Command Palette with Ctrl+Shift+P, or Cmd+Shift+P on Mac. Type Git: Clone, choose that command, paste the repository URL, and choose a folder on your computer where you can find it again.

Jamie: After it clones, VS Code usually asks whether to open the cloned repository. Say yes, because opening the folder is what makes Source Control and the file tree line up with the repo.

Alex: Exactly. You can verify the clone by opening Explorer with Ctrl+Shift+E, or Cmd+Shift+E on Mac. You should hear or see files like README.md, and possibly a docs folder, depending on the repo.

Jamie: Then we need to get off main before editing.

Alex: Yes. Open the Command Palette again and run Git: Create Branch. In the challenge issue, the branch name may be fix/YOUR-USERNAME, where you replace YOUR-USERNAME with your GitHub username. In Learning Room practice, you may use a learn/<username> branch if your cohort is using that convention.

Jamie: I like checking the branch name in the status bar after that. It makes it harder to accidentally commit on main.

Alex: Good habit. Now open README.md or the file named in your issue, make a small edit, and save with Ctrl+S or Cmd+S. A typo fix, a clearer sentence, or one helpful comment is enough.

Jamie: Then Source Control time.

Alex: Open Source Control with Ctrl+Shift+G, or Cmd+Shift+G on Mac. Your changed file appears under Changes. Move to the file and activate the plus button, which stages it. Then type a commit message like docs: improve README wording, and commit with Ctrl+Enter or Cmd+Enter.

Jamie: After the commit, the change list should clear because the snapshot is now saved locally.

Alex: Right. But it is still only local. To share it, open the Command Palette, run Git: Push, and if VS Code asks to publish the branch or set upstream, confirm it. Setting upstream just links your local branch to a branch on GitHub so future pushes know where to go.

---

Jamie: What if someone prefers the terminal? I know some learners hear command line and immediately worry they're doing the harder version.

Alex: The terminal path is direct, not automatically harder. Start by cloning the repo URL your facilitator gave you, for example git clone followed by the URL. Then cd into the folder. A good check before changing anything is git status, and another is git branch --show-current.

Jamie: And to create the branch?

Alex: Use git checkout -b fix/YOUR-USERNAME, replacing the placeholder. Some newer materials also use git switch -c for the same create-and-switch action. Then edit a file in any text editor. You can use VS Code with code README.md, or another editor you already know.

Jamie: Stage and commit are the part where the mental model pays off.

Alex: Yes. Use git add with the file you changed, such as git add README.md or git add docs/welcome.md. Then commit with a clear message, for example git commit -m 'docs: fix typo in welcome page'. A descriptive message helps future you understand why the commit exists.

Jamie: Then push with the upstream link the first time.

Alex: Right: git push -u origin fix/YOUR-USERNAME. The -u connects your local branch to the remote branch named origin, which is GitHub in most cloned repos. After that, plain git push usually works from that branch.

Jamie: Where does GitHub CLI fit in?

Alex: GitHub CLI can shorten the clone step with gh repo clone owner/name, and it often handles authentication smoothly. But even if you use gh to clone, the Git ideas are the same: check status, know your branch, stage intentionally, commit locally, and push.

---

Jamie: GitHub Desktop is the other supported route, and it can feel calmer if you want labeled controls instead of commands.

Alex: Yes. In GitHub Desktop, choose File, then Clone repository. Use the URL tab, paste the repo URL, choose a local path, and select Clone. Once the repo is open, use the Current Branch menu or Branch menu to create a new branch, often fix/YOUR-USERNAME, based on main.

Jamie: Then you open the file in an editor, make the tiny change, and save it.

Alex: When you return to GitHub Desktop, it lists the changed file and shows the diff, which is the before-and-after view of the edit. Write a summary in the bottom-left box, such as docs: improve README wording. Then select Commit to your branch, and finally Publish branch at the top.

Jamie: So Desktop still does clone, branch, edit, commit, push. It just wraps the Git commands in a different interface.

---

Alex: Let's spend a minute on accessible Source Control habits, because they make local Git much less mysterious. In VS Code, Ctrl+Shift+G opens the Source Control panel. Files are grouped by state, so you can tell what is changed, what is staged, and what is ready to commit.

Jamie: When you use a screen reader, the names and states matter. Modified, added, deleted, staged... those words tell you where you are in the process.

Alex: Exactly. Press Enter on a changed file to review the diff. Added and removed lines are identified by the viewer, and you can stage a whole file with the plus button. More advanced users can stage selected lines or chunks, which is useful when one file contains two unrelated edits.

Jamie: And unstaging is allowed. If I staged the wrong file, I can move it back out before committing.

Alex: Yes, staging is reversible before the commit. Committing is more durable, so slow down there and write the message in plain language. A good message often starts with a type like docs or fix, then says what changed: docs: improve welcome page introduction.

---

Jamie: How do I know I actually succeeded after pushing?

Alex: Go to the repository on GitHub.com. You may see a banner saying your branch had recent pushes, with a Compare & pull request button. You should also be able to find your branch in the branch selector and see your commit in that branch's history.

Jamie: And the challenge asks for evidence, not a huge essay.

Alex: Right. In the issue's evidence box, describe the tool you used, the branch name, what file you edited, and your commit message. The automated check is looking for at least one commit on a non-default branch that was pushed from a local tool.

Jamie: Some versions also ask for a peer simulation check, comparing your workflow with a buddy or with the peer-simulation PR notes.

Alex: That's a useful reflection. Maybe your buddy used Desktop while you used VS Code, or they pushed from terminal while you clicked Publish Branch. The interface changed, but the Git workflow stayed recognizable.

Jamie: And to unlock Challenge 11, reply to the issue with a joyful message that you pushed your code, then activate Close issue.

Alex: Yes. Celebrate it. Your computer and GitHub are now talking to each other through Git.

---

Jamie: Let's talk about getting stuck, because cloning and pushing are the two places where people often feel blocked.

Alex: If cloning fails, first check the URL. Make sure you copied the HTTPS or SSH URL from the Code button for the right repository. If it is a private Learning Room repo, you need access with your own GitHub account; if access is denied, ask a facilitator to confirm the Classroom setup.

Jamie: Authentication errors can sound scary, but they often mean the tool needs you to sign in again or use the right credential method.

Alex: Exactly. The Git authentication appendix is there for that setup. If VS Code seems quiet during clone or push, check notifications; the command Notifications: Focus Notification Toast can bring the progress message into focus.

Jamie: What about push rejected?

Alex: First, confirm you committed. Push sends commits, not just saved files. Then run git status to see what Git thinks is happening. If GitHub has changes you do not have locally, fetch or pull before trying again, and make sure you are on the branch you meant to push.

Jamie: And if Source Control doesn't show anything?

Alex: Make sure you opened the cloned folder as the workspace, not just a single file. Press Ctrl+Shift+G or Cmd+Shift+G, and check that the folder is actually a Git repository. If you're unsure what to edit, choose the smallest helpful change: fix a typo, improve a sentence, or add a short note.

Jamie: There are also safety tools for mistakes, right?

Alex: Yes. If you do not want to keep an uncommitted change, you can discard it, but read the prompt carefully because discard can remove work. If you need to temporarily set work aside, stash is safer. Timeline and Git history help you review past commits, blame shows who last changed each line, and reflog can sometimes recover lost local commits or deleted branches.

Jamie: Reflog is local-only, though. If the work never existed on your machine, reflog won't invent it.

Alex: Correct. And with conflicts, remember that a conflict is not a failure. It means Git found overlapping edits and needs a human decision. VS Code can guide you through choosing, combining, or reviewing those changes before committing the resolution.

---

Jamie: I like where this challenge lands. It is not asking for a masterpiece edit. It is asking for a complete loop.

Alex: Clone gives you a local copy. Branch protects main. Edit changes a real file. Stage selects what belongs in the snapshot. Commit saves it locally. Push backs it up on GitHub and makes it visible to the project.

Jamie: And once that branch appears on GitHub with your commit, you've crossed an important line. You're not just using GitHub in the browser anymore. You're working like a contributor with local tools.