Review and release

The bookbinding page works locally. We still need to check it in the deployed layout and confirm that adding a third card hasn't made the existing catalog harder to use. We'll review one saved version and release that version through a pull request.

From the website folder, identify the branch and commit:

git branch --show-current
git status
git log -1 --oneline

The branch should be add-bookbinding and the working tree clean. Record the commit identifier for the review.

Outcome

Review the third workshop on a preview and release the approved catalog update through GitHub.

Hands-on exercise 5.2

Deploy the saved version

Run the preview command from the linked folder:

vercel

Open the returned URL after deployment succeeds. Confirm the Vercel project and Preview environment. Use this specific deployment URL in the review note, so the observations stay connected to the uploaded version.

If the preview fails to build, inspect its build log and fix the reported issue before moving to visual review. Commit a correction and create a new preview. Update the note with the new commit and URL.

Review the full catalog

At desktop width, scan the three cards. The duration labels and prices should be easy to find, and all titles should lead to the correct pages. Check the homepage heading we changed in Section 2 as well; later changes should have preserved it.

Reduce the browser to approximately 375 pixels wide using its responsive view, or open the preview on a phone with authorized access. Look for horizontal scrolling and overlapping text. The third card should fit the same layout rules as the earlier two.

Use Tab and Shift+Tab to move through the header, catalog links, and form fields. Confirm focus remains visible. Open bookbinding with the keyboard and return to the catalog using its page link.

The longer title and extra card can affect the layout even though we only changed the workshop data.

Review the inquiry

Submit one controlled bookbinding inquiry from the preview. Check the pending behavior, acceptance message, and owner inbox. Verify its subject names bookbinding and the configured owner remains the recipient.

Also submit an incomplete form to check field feedback. Keep the Firewall rule from 4.6 enabled. If the test reaches its limit, wait for the window to expire before another controlled send.

Use a brief review note with these entries:

When browser resizing is our only small-screen check, say so in the note. Email delivery stays unresolved if the provider accepted the request but nothing arrived in the inbox; investigate before releasing.

Propose the release

Push the feature branch and open a pull request:

git push -u origin add-bookbinding
gh pr create --base main --head add-bookbinding --title "Add the bookbinding workshop" --body "Add a third workshop through the shared catalog. Review the preview and inquiry evidence before merging."

Substitute the project's production branch for main if needed. The push may also create a Git-triggered preview; check its source if you use that URL instead of the CLI preview.

In GitHub, inspect Files changed. The update should be the new workshop record and any deliberate correction discovered during review. Add the completed review note to the pull request, then follow the repository's review and merge requirements.

Once merged, wait for the production deployment. Confirm it contains the merged change before opening the stable production URL. A squash merge may have a different commit identifier from the feature branch; connect it through the merged pull request.

Try It

Open production in a signed-out browser. Count three workshops and follow the bookbinding link. Check its example price and duration. Send one controlled inquiry and confirm its delivery before recording the release as complete.

Update the local production branch after the release succeeds:

git switch main
git pull --ff-only
git status

The refreshed branch should contain the released workshop and have a clean working tree. We'll create a separate recovery exercise branch from this version next.

The pull request contains unrelated changes

Compare its base branch with the intended production branch. Then inspect the commits included. Correct the branch selection or separate the unrelated work before merging. Check that every change belongs in this release, even if the preview works.

Production shows only two workshops

Check the merge status and the production deployment's source. A preview URL can show an unmerged branch while production still serves the earlier catalog. If the merge deployed unsuccessfully, use its build log to find the issue before attempting another release.

Commit

The workshop commit from 5.1 is the release's source change. If review uncovered a defect, save a focused correction such as fix(catalog): keep workshop facts readable on narrow screens, then review a fresh preview. Don't create a second data entry to mark completion.

Done-When

• The saved version passes the catalog, navigation, and inquiry review.
• The pull request records actual preview observations.
• The merged change appears in a successful production deployment.
• Production shows all three workshops and the controlled inquiry reaches the owner.

Solution

Use these steps to check the bookbinding release:

1. Commit the bookbinding record and deploy its preview.
2. Check the full catalog and one controlled inquiry, recording the actual results.
3. Push add-bookbinding, review its pull request, and merge through the project's process.
4. Verify production and update the local production branch.

Keep the release note for reference. Next, we'll break the form on a separate preview and practice finding the cause.