Lab 7: Branches, Pull Requests, and Automated Tests¶

What you will learn¶

• How teams change the same code without overwriting each other: branches, pull requests, and review
• How to resolve a merge conflict
• How to turn acceptance criteria into automated tests, and run them on every push with GitHub Actions
• How preview deployments and rollbacks let you ship without fear

Parts A and B are done in pairs on a shared practice repo. Parts C to E are on your own project.

Part A: A pull request, reviewed (25 minutes, pairs)¶

Partner A sets up the shared repo:

1. Make a new folder, copy your Lab 2 problem-tracker/index.html into it, and start Claude Code:

   Make this folder a git repo, commit index.html, create a private GitHub repo named lab07-, push to it, and add <partner's GitHub username> as a collaborator.

Partner B accepts the invitation (check email or github.com/notifications) and clones it:

gh repo clone <partner-A-username>/lab07-<initials>

Each partner, separately, makes one small feature on a branch. Ask Claude:

Create a branch named feature/-. Add [a small feature, such as a delete button, a count of open problems, or a dark mode toggle]. Commit, push the branch, and open a pull request with gh pr create. Write a description that says what changed, why, and how to test it.

Then review your partner's pull request on github.com:

1. Open the Files changed tab. Read every line.
2. Pull the branch and run it: gh pr checkout <number>, then open index.html.
3. Leave at least two comments on specific lines: one question and one suggestion.
4. Choose Request changes or Approve.

The author responds to each comment (fix it, or reply explaining why not), pushes the fix, and the reviewer approves. The author merges with Squash and merge.

Part B: A merge conflict, on purpose (10 minutes, pairs)¶

1. Both partners pull the latest main: git switch main && git pull.
2. Each partner makes a branch and changes the same line: the page's <h1> title, to different text. Commit and push both, and open both pull requests.
3. Merge one. The other now shows This branch has conflicts.

4. The second author resolves it locally. Ask Claude:

   My pull request has a merge conflict with main. Merge main into my branch, show me the conflict markers, and explain what each side is. Do not choose for me.

5. Decide what the title should be, remove the conflict markers, commit, push, and merge.

Record in labs/lab-07/team.md: links to both partners' pull requests, and two sentences on how the conflict happened and how you resolved it.

Part C: Tests from your acceptance criteria (15 minutes, your project)¶

Back in your course repo, start Claude Code and ask:

Set up Vitest in app/ if it is not there. Then read specs/user-stories.md and
write automated tests for at least three acceptance criteria, including at least
one about something going wrong. Put each test in a file next to the code it tests.
Name each test after the story and criterion it checks, for example
"S1: rejects an empty amount". Run the tests and show me the output.

Read One test, taken apart and then read each test Claude wrote. For one of them, answer in your reflection: what would have to be broken for this test to fail?

Prove a test can fail. Break the code on purpose (for example, remove the empty-amount check), run npm test, and confirm a test goes red. Undo the change.

Part D: Run the tests on every push (10 minutes)¶

Add a GitHub Actions workflow at .github/workflows/test.yml that installs dependencies and runs the tests in app/ on every push and every pull request. Commit it on a branch called ci/tests, push, and open a pull request.

On github.com, open the pull request and watch the check run. It should go green. Then:

1. Push one more commit to that branch that breaks a test. Watch the check go red on the pull request.
2. Fix it, push, and watch it go green. Merge.
3. Take a screenshot of the pull request's checks (red and then green) for labs/lab-07/.

Optional: in Settings → Branches, add a branch protection rule for main that requires the check to pass before merging. This is how teams make "tests must pass" a rule rather than advice.

Part E: Preview deploys and rollback (after class)¶

1. Open a pull request on your project that makes a visible change. Vercel posts a Preview URL on the pull request. Open it: this is your change running on a real server before it reaches production. Then merge it.
2. In Vercel, open Deployments, find the deployment before your merge, and choose Instant Rollback (or Promote to Production). Confirm your live site shows the old version. Then promote the latest deployment again.

Record both URLs in labs/lab-07/deploys.md, following Rolling Back a Bad Deploy.

Reflection¶

Write labs/lab-07/reflection.md:

1. What did your partner's review catch that you missed? What did you catch in theirs?
2. For one test: what would have to be broken for it to fail? If you cannot answer, what does that say about the test?
3. Name one piece of technical debt in your project right now. Is it strategic or accidental (the quadrant)? When would you pay it down?

Turn in¶

Submit the link to labs/lab-07/ on Canvas. It should contain:

• team.md with links to both partners' reviewed and merged pull requests
• At least three passing tests in your project, and the GitHub Actions workflow
• Screenshot of a red and then green check, deploys.md, and reflection.md

Next: the Peer Code Review is assigned today and due Mon, Dec 7. It applies Part A's review skills to a classmate's whole system.

How larger systems do this¶

Large engineering organizations merge thousands of pull requests a day into the same codebase. That is only possible because of what you set up today, at a larger scale: every change on a short-lived branch, at least one reviewer required, a test suite of thousands of tests that must pass before merge, preview and staging environments that mirror production, feature flags that turn new code on for a few users at a time, and one-click rollback when something goes wrong anyway. Read What it looks like on a team for how this works when several people, and several agents, work on one repo.