Alex: Welcome back. Challenge 11 is called Open a Day 2 PR, and this is the moment your local Git work becomes a GitHub conversation.

Jamie: So we already did the local part in Challenge 10: clone, branch, edit, stage, commit, and push. Now we are proposing that branch for review.

Alex: Exactly. Your commits started on your machine, but a pull request lives on GitHub. A pull request, or PR, is the place where you describe the change, compare it against `main`, let checks run, and invite review.

Jamie: And if someone joined Day 2 without Day 1, this is still doable as long as they have the GitHub basics and have completed the Day 2 Quick Start readiness check.

---

Alex: The pattern is familiar from Day 1, but the route is different. Day 1 was edit on GitHub.com, commit, open a PR. Day 2 is edit locally, commit locally, push to GitHub, then open a PR.

Jamie: That helps. The PR step did not become a whole new skill. The commits just came from a different place.

Alex: Right. Git is moving your work between locations: your working folder, your local repository history, and GitHub. Once the branch is on GitHub, the PR creation step feels very much like the browser workflow you already practiced.

Jamie: So if I am nervous, I should not treat this as a brand-new mountain. It is the same review doorway, with one extra push step before it.

---

Alex: Before opening the PR, confirm that your branch really made it to GitHub. In VS Code, the Source Control panel should be clean after your commit and push, meaning no staged or unstaged changes are waiting.

Jamie: And if I like the terminal, I can check the same thing with `git status`, right?

Alex: Yes. `git status` tells you whether your working tree is clean and whether your branch is ahead of or behind GitHub. `git branch --show-current` tells you which branch you are on, and `git fetch` followed by `git status` helps confirm that your local view is up to date before you push or open the PR.

Jamie: What branch name should people expect?

Alex: Use the branch your challenge issue assigned. In some Day 2 materials you will see examples like `fix/YOUR-USERNAME`, `learn/<username>`, or `feature/day2-local-edit`. The important part is not the exact example name. It is that your compare branch is the branch with your Day 2 commit, and your base branch is usually `main`.

Jamie: That also explains the VS Code pieces from the Git practice chapter: branch name in the status bar, changed files in Source Control, staged changes, commit message, and push status.

Alex: Yes, and there are safety tools around that workflow. Timeline helps you inspect file history. Stash can set unfinished work aside without deleting it. Discard is for throwing away changes, so use it carefully. If a merge conflict appears, VS Code can show conflict choices, and if you truly lose track of a local commit, `git reflog` can help you find recent local history.

Jamie: Good to know, but for this challenge we are hoping for the calm version: one branch, at least one commit, pushed to GitHub, ready for a PR.

---

Alex: The quickest browser path is the notification banner. Go to the assigned repository on GitHub.com, such as the sci-fi themes repository if that is what your challenge uses. If GitHub notices your recent push, it may show a banner with a Compare & pull request button.

Jamie: That banner is a shortcut, not a requirement. If I hear it or see it, I can use it and skip the manual compare setup.

Alex: Exactly. If there is no banner, open the Pull requests tab, choose New pull request, set base to `main`, and set compare to your Day 2 branch. Then choose Create pull request to reach the form.

Jamie: The base is where I want the change to land. The compare branch is where my change currently lives.

---

Alex: You can also create the PR inside VS Code if the GitHub Pull Requests and Issues extension is installed and you are signed in. Open the GitHub Pull Requests view from the Activity Bar, or use the Command Palette with `Ctrl+Shift+P`, or `Cmd+Shift+P` on Mac.

Jamie: Then I run GitHub Pull Requests: Create Pull Request?

Alex: Yes. You can run that command, or select the Create Pull Request button in the Pull Requests view. Choose your compare branch, choose `main` as the base branch, enter a clear title, add a short description, and activate Create.

Jamie: And the extension is useful beyond creating PRs. It can list PRs, show details, open changed files, and let me work with reviews without constantly switching back to the browser.

---

Alex: If you use GitHub CLI, the command is `gh pr create`. It opens an interactive PR creator in the terminal.

Jamie: Interactive means it asks me questions instead of making me remember every option.

Alex: Right. Give the PR a clear title, choose to write the body in your editor if that is comfortable, summarize what changed, and when it asks what is next, choose Submit. You can also use inline options later, but the guided prompts are a solid starting point.

Jamie: So the three doors are browser, VS Code, and `gh pr create`. They all lead to the same PR on GitHub.

---

Alex: Now slow down for the title and description. A title like `docs: improve README wording` tells reviewers the type of change and the area touched.

Jamie: That is much better than `updates` or `stuff fixed`, which makes everyone open the diff just to learn the basics.

Alex: For the description, write a few plain sentences. You might include a short Changes area, a How I made these changes area, and a Pattern recognition note. For example: I cloned the repo locally, created a branch, edited in VS Code, committed, pushed, and opened this PR. Compared with Day 1, this started from a local clone, may have more than one commit, and required `git push` before the PR.

Jamie: And if the PR should close an issue, include plain text like `Closes #8`, using the real issue number.

Alex: Yes. The reference solution shows that kind of professional PR: a specific title, a list of changes, a short explanation of how the work was made, and a note about what changed from Day 1. That is the evidence reviewers need to understand your path.

Jamie: It also makes the pattern visible to future you. You are not just submitting a link. You are explaining the workflow you used.

---

Alex: After the PR exists, read it. In the browser, check the Conversation and Files changed tabs. In VS Code, the GitHub Pull Requests extension can open the PR details and changed files.

Jamie: This is where the code review chapter starts to matter. I am not reviewing someone else yet, but I can still inspect my own PR like a reviewer would.

Alex: Exactly. Read the title and description first, then open the changed files. If the diff editor is hard to follow, use the Accessible Diff Viewer with `F7` for the next change and `Shift+F7` for the previous change. It reads changes in chunks, which is usually easier than moving line by line through a visual diff.

Jamie: The challenge also mentions a peer-simulation check. That means I should look at the sample PR title and description and ask whether they clearly explain what changed. If I have real buddy access, I can review my buddy's PR too.

Alex: Yes. And when you leave review comments later, be specific and constructive. A useful comment points to the issue, explains why it matters, and suggests a next step when possible.

Jamie: That is a good habit even when the change is tiny. The PR is both a code artifact and a communication artifact.

---

Alex: Once the PR is open, Gandalf should run automated checks and post a validation report in the PR conversation. If Gandalf is quiet, open the Checks tab and see whether the workflow is running, waiting, or failed.

Jamie: What if my branch does not appear in the compare dropdown?

Alex: First, make sure the push completed. From your local tool, you can run `git push -u origin fix/YOUR-USERNAME`, replacing the branch name with yours. If GitHub says there is nothing to compare, your branch may not contain any new commits compared with `main`, so confirm you committed and pushed at least one change.

Jamie: And if I do not know what to write in the description, I can reuse the same shape from the earlier PR challenge: what changed and why.

---

Alex: To finish Challenge 11, paste the URL of your Day 2 PR into the evidence field. Then describe the pattern you noticed between the Day 1 PR and the Day 2 PR.

Jamie: Something like: Day 1 used the web editor, Day 2 used a local clone and required a push, but both ended with a PR against `main`.

Alex: Perfect. Then activate Close issue when the challenge asks you to. If you created a PR from your locally pushed branch, waited for validation, and explained the workflow pattern, you completed the challenge.

Jamie: That is the real win here: local work did not stay trapped on your machine. You moved it into a reviewable GitHub workflow.